Merged master in and resolved some minor conflicts in parsing.py related to supporting older versions of attrs

4 files changed, 143 insertions, 132 deletions

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 0736d893..e4de4fd4 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,39 +1,40 @@
-# Contributor's Guide
+# Contributor's guide
 
 We welcome pull requests from cmd2 users and seasoned Python developers alike! Follow these steps to contribute:
 
-1. Find an issue that needs assistance by searching for the [Help Wanted](https://github.com/python-cmd2/cmd2/labels/help%20wanted) tag.
+1. Find an issue that needs assistance by searching for the [Help Wanted](https://github.com/python-cmd2/cmd2/labels/help%20wanted) tag
 
-2. Let us know you are working on it by posting a comment on the issue.
+2. Let us know you're working on it by posting a comment on the issue
 
-3. Follow the [Contribution Guidelines](#contribution-guidelines) to start working on the issue.
+3. Follow the [Contribution guidelines](#contribution-guidelines) to start working on the issue
 
 Remember to feel free to ask for help by leaving a comment within the Issue.
 
-Working on your first Pull Request? You can learn how from this *free* series [How to Contribute to an Open Source Project on GitHub](https://egghead.io/series/how-to-contribute-to-an-open-source-project-on-github).
+Working on your first pull request? You can learn how from this *free* series [How to Contribute to an Open Source Project on GitHub](https://egghead.io/series/how-to-contribute-to-an-open-source-project-on-github).
 
-###### If you've found a bug that is not on the board, [follow these steps](#found-a-bug).
+###### If you've found a bug that is not on the board, [follow these steps](Readme.md#found-a-bug).
 
 --------------------------------------------------------------------------------
 
-## Contribution Guidelines
+## Contribution guidelines
 
 - [Prerequisites](#prerequisites)
-- [Forking The Project](#forking-the-project)
-- [Create A Branch](#create-a-branch)
-- [Setup for cmd2 development](#setup-for-cmd2-development)
-- [Make Changes](#make-changes)
-- [Static Code Analysis](#static-code-analysis)
-- [Run The Test Suite](#run-the-test-suite)
-- [Squash Your Commits](#squash-your-commits)
-- [Creating A Pull Request](#creating-a-pull-request)
-- [Common Steps](#common-steps)
-- [How We Review and Merge Pull Requests](#how-we-review-and-merge-pull-requests)
-- [How We Close Stale Issues](#how-we-close-stale-issues)
-- [Next Steps](#next-steps)
+- [Forking the project](#forking-the-project)
+- [Creating a branch](#creating-a-branch)
+- [Setting up for cmd2 development](#setting-up-for-cmd2-development)
+- [Making changes](#making-changes)
+- [Static code analysis](#static-code-analysis)
+- [Running the test suite](#running-the-test-suite)
+- [Squashing your commits](#squashing-your-commits)
+- [Creating a pull request](#creating-a-pull-request)
+- [Common steps](#common-steps)
+- [How we review and merge pull requests](#how-we-review-and-merge-pull-requests)
+- [How we close stale issues](#how-we-close-stale-issues)
+- [Next steps](#next-steps)
 - [Other resources](#other-resources)
 - [Advice](#advice)
 - [Developing in an IDE](#developing-in-an-ide)
+- [Publishing a new release](#publishing-a-new-release)
 
 ### Prerequisites
 
@@ -45,25 +46,29 @@ The tables below list all prerequisites along with the minimum required version
 
 | Prerequisite                                        | Minimum Version |
 | --------------------------------------------------- | --------------- |
-| [Python](https://www.python.org/downloads/)         | `3.4`           |
-| [pyperclip](https://github.com/asweigart/pyperclip) | `1.6`           |
+| [python](https://www.python.org/downloads/)         | `3.4`           |
+| [attrs](https://github.com/python-attrs/attrs)      | `16.3`          |
+| [colorama](https://github.com/tartley/colorama)     | `0.3.7`         |
+| [pyperclip](https://github.com/asweigart/pyperclip) | `1.5.27`        |
+
 
 #### Additional prerequisites to run cmd2 unit tests
 
 | Prerequisite                                | Minimum Version |
 | ------------------------------------------- | --------------- |
-| [pytest](http://doc.pytest.org/en/latest/)  | `2.6.3`         |
+| [pytest](http://doc.pytest.org/en/latest/)  | `3.0.6`         |
+| [pytest-mock](https://pypi.org/project/pytest-mock/) | `1.3`  |
 
-### Additional prerequisites to build cmd2 documentation
+#### Additional prerequisites to build cmd2 documentation
 | Prerequisite                                | Minimum Version |
 | ------------------------------------------- | --------------- |
-| [sphinx](http://www.sphinx-doc.org)         | `1.2.3`         |
-| [sphinx-rtd-theme](https://github.com/snide/sphinx_rtd_theme) | `0.1.6` |
+| [sphinx](http://www.sphinx-doc.org)         | `1.4.9`         |
+| [sphinx-rtd-theme](https://github.com/snide/sphinx_rtd_theme) | `0.1.9` |
 
-### Optional prerequisites for enhanced unit test features
+#### Optional prerequisites for enhanced unit test features
 | Prerequisite                                | Minimum Version |
 | ------------------------------------------- | --------------- |
-| [pytest-cov](https://pypi.python.org/pypi/pytest-cov) | `1.8` |
+| [pytest-cov](https://pypi.python.org/pypi/pytest-cov) | `2.4` |
 
 If Python is already installed in your machine, run the following commands to validate the versions:
 
@@ -74,36 +79,32 @@ $ pip freeze | grep pyperclip
 
 If your versions are lower than the prerequisite versions, you should update.
 
-If you do not already have Python installed on your machine, we recommend using the [Anaconda](https://www.continuum.io/downloads) distribution because it provides an excellent out-of-the-box install on all Platforms (Windows, Mac, or Linux) and because it supports having multiple Python environments (versions of Python) installed simultaneously.
+If you do not already have Python installed on your machine, we recommend using the [Anaconda](https://www.continuum.io/downloads) distribution because it provides an excellent out-of-the-box install on all platforms (Windows, Mac, and Linux) and because it supports having multiple Python environments (versions of Python) installed simultaneously.
 
-### Forking The Project
+### Forking the project
 
-#### Setting Up Your System
+#### Setting up your system
 
 1. Install [Git](https://git-scm.com/) or your favorite Git client.  If you aren't comfortable with Git at the command-line, then both [SmartGit](http://www.syntevo.com/smartgit/) and [GitKraken](https://www.gitkraken.com) are excellent cross-platform graphical Git clients.
-2. (Optional) [Setup an SSH Key](https://help.github.com/articles/generating-an-ssh-key/) for GitHub.
-3. Create a parent projects directory on your system. For this guide, it will be assumed that it is `~/src`
+2. (Optional) [Set up an SSH key](https://help.github.com/articles/generating-an-ssh-key/) for GitHub.
+3. Create a parent projects directory on your system. For this guide, it will be assumed that it is `~/src`.
 
 #### Forking cmd2
 
-1. Go to the top level cmd2 repository: <https://github.com/python-cmd2/cmd2>
-2. Click the "Fork" Button in the upper right hand corner of the interface ([More Details Here](https://help.github.com/articles/fork-a-repo/))
+1. Go to the top-level cmd2 repository: <https://github.com/python-cmd2/cmd2>
+2. Click the "Fork" button in the upper right hand corner of the interface ([more details here](https://help.github.com/articles/fork-a-repo/))
 3. After the repository has been forked, you will be taken to your copy of the cmd2 repo at `yourUsername/cmd2`
 
-#### Cloning Your Fork
+#### Cloning your fork
 
-1. Open a Terminal / Command Line / Bash Shell in your projects directory (_i.e.: `/yourprojectdirectory/`_)
-2. Clone your fork of cmd2
+1. Open a terminal / command line / Bash shell in your projects directory (_e.g.: `~/src/`_)
+2. Clone your fork of cmd2, making sure to replace `yourUsername` with your GitHub username. This will download the entire cmd2 repo to your projects directory.
 
 ```sh
 $ git clone https://github.com/yourUsername/cmd2.git
 ```
 
-##### (make sure to replace `yourUsername` with your GitHub Username)
-
-This will download the entire cmd2 repo to your projects directory.
-
-#### Setup Your Upstream
+#### Set up your upstream
 
 1. Change directory to the new cmd2 directory (`cd cmd2`)
 2. Add a remote to the official cmd2 repo:
@@ -114,11 +115,11 @@ $ git remote add upstream https://github.com/python-cmd2/cmd2.git
 
 Congratulations, you now have a local copy of the cmd2 repo!
 
-#### Maintaining Your Fork
+#### Maintaining your fork
 
 Now that you have a copy of your fork, there is work you will need to do to keep it current.
 
-##### **Rebasing from Upstream**
+##### **Rebasing from upstream**
 
 Do this prior to every time you create a branch for a PR:
 
@@ -130,13 +131,13 @@ Do this prior to every time you create a branch for a PR:
   > Your branch is up-to-date with 'origin/master'.
   > ```
 
-  > If your aren't on `master`, resolve outstanding files / commits and checkout the `master` branch
+  > If your aren't on `master`, resolve outstanding files and commits and checkout the `master` branch
 
   > ```sh
   > $ git checkout master
   > ```
 
-2. Do A Pull with Rebase Against `upstream`
+2. Do a pull with rebase against `upstream`
 
   > ```sh
   > $ git pull --rebase upstream master
@@ -152,15 +153,15 @@ Do this prior to every time you create a branch for a PR:
 
   > This will overwrite the master branch of your fork.
 
-### Create A Branch
+### Creating a branch
 
-Before you start working, you will need to create a separate branch specific to the issue / feature you're working on. You will push your work to this branch.
+Before you start working, you will need to create a separate branch specific to the issue or feature you're working on. You will push your work to this branch.
 
-#### Naming Your Branch
+#### Naming your branch
 
 Name the branch something like `fix/xxx` or `feature/xxx` where `xxx` is a short description of the changes or feature you are attempting to add. For example `fix/script-files` would be a branch where you fix something specific to script files.
 
-#### Adding Your Branch
+#### Adding your branch
 
 To create a branch on your local machine (and switch to this branch):
 
@@ -177,7 +178,7 @@ $ git push origin [name_of_your_new_branch]
 ##### If you need more help with branching, take a look at _[this](https://github.com/Kunena/Kunena-Forum/wiki/Create-a-new-branch-with-git-and-manage-branches)_.
 
 
-### Setup for cmd2 development
+### Setting up for cmd2 development
 For doing cmd2 development, you actually do NOT want to have cmd2 installed as a Python package.
 So if you have previously installed cmd2, make sure to uninstall it:
 ```sh
@@ -203,11 +204,11 @@ $ pip install -e .[dev]
 This project uses many python modules for various development tasks, including
 testing, rendering documentation, and building and distributing releases. These
 modules can be configured many different ways, which can make it difficult to
-learn the specific incantations required for each project you are familiar with.
+learn the specific incantations required for each project you're familiar with.
 
-This project uses `invoke <http://www.pyinvoke.org>`_ to provide a clean, high
-level interface for these development tasks. To see the full list of functions
-available::
+This project uses `invoke <http://www.pyinvoke.org>` to provide a clean,
+high-level interface for these development tasks. To see the full list of functions
+available:
 ```sh
 $ invoke -l
 ```
@@ -232,21 +233,21 @@ $ python examples/example.py
 
 If the example app loads, you should see a prompt that says "(Cmd)".  You can
 type `help` to get help or `quit` to quit. If you see that, then congratulations
-– you're all set. Otherwise, refer to the cmd2 [Installation Instructions](https://cmd2.readthedocs.io/en/latest/install.html#installing).
-There also might be an error in the console of your Bash / Terminal / Command Line
+– you're all set. Otherwise, refer to the cmd2 [installation instructions](https://cmd2.readthedocs.io/en/latest/install.html#installing).
+There also might be an error in the console of your Bash / terminal / command line
 that will help identify the problem.
 
-### Make Changes
+### Making changes
 This bit is up to you!
 
-#### How to find the code in the cmd2 codebase to fix/edit?
+#### How to find code in the cmd2 codebase to fix/edit
 
 The cmd2 project directory structure is pretty simple and straightforward.  All
 actual code for cmd2 is located underneath the `cmd2` directory.  The code to
 generate the documentation is in the `docs` directory.  Unit tests are in the
 `tests` directory.  The `examples` directory contains examples of how to use
 cmd2.  There are various other files in the root directory, but these are
-primarily related to continuous integration and to release deployment.
+primarily related to continuous integration and release deployment.
 
 #### Changes to the documentation files
 
@@ -255,7 +256,7 @@ Sphinx documentation and make sure your changes look good:
 ```sh
 $ invoke docs
 ```
-In order to see the changes, use your web browser of choice to open `<cmd2>/docs/_build/html/index.html`.
+In order to see the changes, use your web browser of choice to open `~/cmd2/docs/_build/html/index.html`.
 
 If you would rather use a webserver to view the documentation, including
 automatic page refreshes as you edit the files, use:
@@ -265,48 +266,46 @@ $ invoke livehtml
 ```
 
 You will be shown the IP address and port number where the documents are now
-served (usually [http://localhost:8000](http://localhost:8000).
+served (usually [http://localhost:8000](http://localhost:8000)).
 
-### Static Code Analysis
+### Static code analysis
 
-You should have some sort of [PEP8](https://www.python.org/dev/peps/pep-0008/)-based linting running in your editor or IDE or at the command-line before you commit code.  [pylint](https://www.pylint.org) is a good Python linter which can be run at the command-line but also can integrate with many IDEs and editors.
+You should have some sort of [PEP 8](https://www.python.org/dev/peps/pep-0008/)-based linting running in your editor or IDE or at the command line before you commit code.  [pylint](https://www.pylint.org) is a good Python linter which can be run at the command line but also can integrate with many IDEs and editors.
 
 > Please do not ignore any linting errors in code you write or modify, as they are meant to **help** you and to ensure a clean and simple code base.  Don't worry about linting errors in code you don't touch though - cleaning up the legacy code is a work in progress.
 
-### Run The Test Suite
+### Running the test suite
 When you're ready to share your code, run the test suite:
 ```sh
-$ cd <cmd2>
+$ cd ~/cmd2
 $ invoke pytest
 ```
 and ensure all tests pass.
 
 Running the test suite also calculates test code coverage. A summary of coverage
-is shown on the screen. A full report is available in `<cmd2>/htmlcov/index.html`.
+is shown on the screen. A full report is available in `~/cmd2/htmlcov/index.html`.
 
-### Squash Your Commits
+### Squashing your commits
 When you make a pull request, it is preferable for all of your changes to be in one commit.
-
 If you have made more then one commit, then you can _squash_ your commits.
+To do this, see [this article](http://forum.freecodecamp.com/t/how-to-squash-multiple-commits-into-one-with-git/13231).
 
-To do this, see [Squashing Your Commits](http://forum.freecodecamp.com/t/how-to-squash-multiple-commits-into-one-with-git/13231).
-
-### Creating A Pull Request
+### Creating a pull request
 
-#### What is a Pull Request?
+#### What is a pull request?
 
 A pull request (PR) is a method of submitting proposed changes to the cmd2
-Repo (or any Repo, for that matter). You will make changes to copies of the
+repo (or any repo, for that matter). You will make changes to copies of the
 files which make up cmd2 in a personal fork, then apply to have them
 accepted by cmd2 proper.
 
-#### Need Help?
+#### Need help?
 
 GitHub has a good guide on how to contribute to open source [here](https://opensource.guide/how-to-contribute/).
 
 #### Important: ALWAYS EDIT ON A BRANCH
 
-Take away only one thing from this document, it should be this: Never, **EVER**
+If you take away only one thing from this document, it should be this: Never, **EVER**
 make edits to the `master` branch. ALWAYS make a new branch BEFORE you edit
 files. This is critical, because if your PR is not accepted, your copy of
 master will be forever sullied and the only way to fix it is to delete your
@@ -319,13 +318,13 @@ There are two methods of creating a pull request for cmd2:
 -   Editing files on a local clone (recommended)
 -   Editing files via the GitHub Interface
 
-##### Method 1: Editing via your Local Fork _(Recommended)_
+##### Method 1: Editing via your local fork _(recommended)_
 
-This is the recommended method. Read about [How to Setup and Maintain a Local
-Instance of cmd2](#maintaining-your-fork).
+This is the recommended method. Read about [how to set up and maintain a local
+instance of cmd2](#maintaining-your-fork).
 
-1.  Perform the maintenance step of rebasing `master`.
-2.  Ensure you are on the `master` branch using `git status`:
+1.  Perform the maintenance step of rebasing `master`
+2.  Ensure you're on the `master` branch using `git status`:
 
 ```sh
 $ git status
@@ -335,7 +334,7 @@ Your branch is up-to-date with 'origin/master'.
 nothing to commit, working directory clean
 ```
 
-1.  If you are not on master or your working directory is not clean, resolve
+1.  If you're not on master or your working directory is not clean, resolve
     any outstanding files/commits and checkout master `git checkout master`
 
 2.  Create a branch off of `master` with git: `git checkout -B
@@ -345,69 +344,69 @@ nothing to commit, working directory clean
 
 3.  Edit your file(s) locally with the editor of your choice
 
-4.  Check your `git status` to see unstaged files.
+4.  Check your `git status` to see unstaged files
 
 5.  Add your edited files: `git add path/to/filename.ext` You can also do: `git
     add .` to add all unstaged files. Take care, though, because you can
     accidentally add files you don't want added. Review your `git status` first.
 
-6.  Commit your edits: `git commit -m "Brief Description of Commit"`. Do not add the issue number in the commit message.
+6.  Commit your edits: `git commit -m "Brief description of commit"`. Do not add the issue number in the commit message.
 
-7.  Squash your commits, if there are more than one.
+7.  Squash your commits, if there are more than one
 
 8.  Push your commits to your GitHub Fork: `git push -u origin branch/name-here`
 
-9.  Go to [Common Steps](#common-steps)
+9.  Go to [Common steps](#common-steps)
 
-##### Method 2: Editing via the GitHub Interface
+##### Method 2: Editing via the GitHub interface
 
 Note: Editing via the GitHub Interface is not recommended, since it is not
 possible to update your fork via GitHub's interface without deleting and
 recreating your fork.
 
-If you really want to go this route which isn't recommended, you can Google for more information on
+If you really want to go this route (which isn't recommended), you can Google for more information on
 how to do it.
 
-### Common Steps
+### Common steps
 
 1.  Once the edits have been committed, you will be prompted to create a pull
-    request on your fork's GitHub Page.
+    request on your fork's GitHub page
 
 2.  By default, all pull requests should be against the cmd2 main repo, `master`
-    branch.
+    branch
 
-3.  Submit a pull request from your branch to cmd2's `master` branch.
+3.  Submit a pull request from your branch to cmd2's `master` branch
 
 4.  The title (also called the subject) of your PR should be descriptive of your
-    changes and succinctly indicates what is being fixed.
+    changes and succinctly indicate what is being fixed
 
-    -   **Do not add the issue number in the PR title or commit message.**
+    -   **Do not add the issue number in the PR title or commit message**
 
-    -   Examples: `Add Test Cases for Unicode Support` `Correct typo in Overview documentation`
+    -   Examples: `Add test cases for Unicode support`; `Correct typo in overview documentation`
 
 5.  In the body of your PR include a more detailed summary of the changes you
-    made and why.
+    made and why
 
     -   If the PR is meant to fix an existing bug/issue, then, at the end of
         your PR's description, append the keyword `closes` and #xxxx (where xxxx
         is the issue number). Example: `closes #1337`. This tells GitHub to
-        close the existing issue, if the PR is merged.
+        close the existing issue if the PR is merged.
 
 6.  Indicate what local testing you have done (e.g. what OS and version(s) of Python did you run the
     unit test suite with)
 
 7.  Creating the PR causes our continuous integration (CI) systems to automatically run all of the
-    unit tests on all supported OSes and all supported versions of Python.  You should watch your PR
+    unit tests on all supported OSes and all supported versions of Python. You should watch your PR
     to make sure that all unit tests pass on TravisCI (Linux), AppVeyor (Windows), and VSTS (macOS).
 
-8.  If any unit tests fail, you should look at the details and fix the failures.  You can then push
-    the fix to the same branch in your fork and the PR will automatically get updated and the CI system
+8.  If any unit tests fail, you should look at the details and fix the failures. You can then push
+    the fix to the same branch in your fork. The PR will automatically get updated and the CI system
     will automatically run all of the unit tests again.
 
 
-### How We Review and Merge Pull Requests
+### How we review and merge pull requests
 
-cmd2 has a team of volunteer Maintainers. These Maintainers routinely go through open pull requests in a process called [Quality Assurance](https://en.wikipedia.org/wiki/Quality_assurance) (QA).  We also utilize multiple continuous
+cmd2 has a team of volunteer Maintainers. These Maintainers routinely go through open pull requests in a process called [Quality Assurance](https://en.wikipedia.org/wiki/Quality_assurance) (QA).  We also use multiple continuous
 integration (CI) providers to automatically run all of the unit tests on multiple operating systems and versions of Python.
 
 1. If your changes can merge without conflicts and all unit tests pass for all OSes and supported versions of Python,
@@ -422,15 +421,15 @@ and doesn't present any backward compatibility issues, they will merge the pull
 If you would like to apply to join our Maintainer team, message [@tleonhardt](https://github.com/tleonhardt) with links to 5 of your pull requests that have been accepted.
 
 
-### How We Close Stale Issues
+### How we close stale issues
 
 We will close any issues that have been inactive for more than 60 days or pull requests that have been
-inactive for more than 30 days, except those that match the following criteria:
+inactive for more than 30 days, except those that match any of the following criteria:
 - bugs that are confirmed
 - pull requests that are waiting on other pull requests to be merged
 - features that are part of a cmd2 GitHub Milestone or Project
 
-### Next Steps
+### Next steps
 
 #### If your PR is accepted
 
@@ -445,7 +444,7 @@ delete the local copy of the branch with: `git branch -D branch/to-delete-name`
 Don't despair! You should receive solid feedback from the Maintainers as to
 why it was rejected and what changes are needed.
 
-Many Pull Requests, especially first Pull Requests, require correction or
+Many pull requests, especially first pull requests, require correction or
 updating. If you have used the GitHub interface to create your PR, you will need
 to close your PR, create a new branch, and re-submit.
 
@@ -458,11 +457,11 @@ Be sure to post in the PR conversation that you have made the requested changes.
 
 ### Other resources
 
--   [PEP8 Style Guide for Python Code](https://www.python.org/dev/peps/pep-0008/)
+-   [PEP 8 Style Guide for Python Code](https://www.python.org/dev/peps/pep-0008/)
 
--   [Searching for Your Issue on GitHub](https://help.github.com/articles/searching-issues/)
+-   [Searching for your issue on GitHub](https://help.github.com/articles/searching-issues/)
 
--   [Creating a New GitHub Issue](https://help.github.com/articles/creating-an-issue/)
+-   [Creating a new GitHub issue](https://help.github.com/articles/creating-an-issue/)
 
 ### Advice
 
@@ -472,30 +471,30 @@ Here is some advice regarding what makes a good pull request (PR) from the persp
 - Good unit/functional tests are very important
 - Accurate documentation is also important
 - Adding new features is of the lowest importance, behind bug fixes, unit test additions/improvements, code cleanup, and documentation
-- It's best to create a dedicated branch for a PR and use it only for that PR (and delete it once the PR has been merged)
+- It's best to create a dedicated branch for a PR, use it only for that PR, and delete it once the PR has been merged
 - It's good if the branch name is related to the PR contents, even if it's just "fix123" or "add_more_tests"
-- Code coverage of the unit tests matters, try not to decrease it
-- Think twice before adding dependencies to 3rd party libraries (outside of the Python standard library) because it could affect a lot of users
+- Code coverage of the unit tests matters, so try not to decrease it
+- Think twice before adding dependencies to third-party libraries (outside of the Python standard library) because it could affect a lot of users
 
 ### Developing in an IDE
 
-We recommend using [Visual Studio Code](https://code.visualstudio.com) with the [Python extension](https://code.visualstudio.com/docs/languages/python) and it's [Integrated Terminal](https://code.visualstudio.com/docs/python/debugging) debugger for debugging since it has
+We recommend using [Visual Studio Code](https://code.visualstudio.com) with the [Python extension](https://code.visualstudio.com/docs/languages/python) and its [Integrated Terminal](https://code.visualstudio.com/docs/python/debugging) debugger for debugging since it has
 excellent support for debugging console applications.
 
-[PyCharm](https://www.jetbrains.com/pycharm/) is also quite good and has very nice [Code Inspection](https://www.jetbrains.com/help/pycharm/code-inspection.html) capabilities.
+[PyCharm](https://www.jetbrains.com/pycharm/) is also quite good and has very nice [code inspection](https://www.jetbrains.com/help/pycharm/code-inspection.html) capabilities.
 
 ## Publishing a new release
 
 Since 0.9.2, the process of publishing a new release of `cmd2` to [PyPi](https://pypi.org/) has been
 mostly automated. The manual steps are all git operations. Here's the checklist:
 
-1. Make sure you are on the proper branch
-2. Make sure the version strings in `cmd2.py`, `conf.py`, `setup.py`, and `test_cmd2.py` are correct.
-3. Make sure all the unit tests pass.
-4. Make sure `CHANGELOG.md` describes the version and has the correct release date.
-5. Create and push a git tag that matches the version strings above.
-6. (Optional) Run `invoke pypi_test` to clean, build, and upload a new release to [Test PyPi](https://test.pypi.org)
-7. Run `invoke pypi` to clean, build, and upload a new release to [PyPi](https://pypi.org/)
+1. Make sure you're on the proper branch (almost always **master**)
+1. Make sure all the unit tests pass wih `invoke pypi-test` or `py.test`
+1. Make sure `CHANGELOG.md` describes the version and has the correct release date
+1. Add a git tag representing the version number using ``invoke tag x.y.z`` 
+    * Where x, y, and z are all small non-negative integers
+1. (Optional) Run `invoke pypi_test` to clean, build, and upload a new release to [Test PyPi](https://test.pypi.org)
+1. Run `invoke pypi` to clean, build, and upload a new release to [PyPi](https://pypi.org/)
 
 ## Acknowledgement
 Thanks to the good folks at [freeCodeCamp](https://github.com/freeCodeCamp/freeCodeCamp) for creating
diff --git a/README.md b/README.md
index 8cb356a2..92f0d7de 100755
--- a/README.md
+++ b/README.md
@@ -259,3 +259,15 @@ timing: False
 Note how a regular expression `/(True|False)/` is used for output of the **show color** command since
 colored text is currently not available for cmd2 on Windows.  Regular expressions can be used anywhere within a
 transcript file simply by enclosing them within forward slashes, `/`.
+
+
+Found a bug?
+------------
+
+If you think you've found a bug, please first read through the open [Issues](https://github.com/python-cmd2/cmd2/issues). If you're confident it's a new bug, go ahead and create a new GitHub issue. Be sure to include as much information as possible so we can reproduce the bug.  At a minimum, please state the following:
+
+* ``cmd2`` version
+* Python version
+* OS name and version
+* What you did to cause the bug to occur
+* Include any trackeback or error message associated with the bug
diff --git a/cmd2/parsing.py b/cmd2/parsing.py
index 92dc1b40..1d22ccb8 100644
--- a/cmd2/parsing.py
+++ b/cmd2/parsing.py
@@ -81,34 +81,34 @@ class Statement(str):
        argv[1:], which strips them all off for you.
     """
     # the arguments, but not the command, nor the output redirection clauses.
-    args = attr.ib(default='', validator=attr.validators.instance_of(str), type=str)
+    args = attr.ib(default='', validator=attr.validators.instance_of(str))
 
     # string containing exactly what we input by the user
-    raw = attr.ib(default='', validator=attr.validators.instance_of(str), type=str)
+    raw = attr.ib(default='', validator=attr.validators.instance_of(str))
 
     # the command, i.e. the first whitespace delimited word
-    command = attr.ib(default='', validator=attr.validators.instance_of(str), type=str)
+    command = attr.ib(default='', validator=attr.validators.instance_of(str))
 
     # list of arguments to the command, not including any output redirection or terminators; quoted args remain quoted
-    arg_list = attr.ib(default=attr.Factory(list), validator=attr.validators.instance_of(list), type=List[str])
+    arg_list = attr.ib(default=attr.Factory(list), validator=attr.validators.instance_of(list))
 
     # if the command is a multiline command, the name of the command, otherwise empty
-    multiline_command = attr.ib(default='', validator=attr.validators.instance_of(str), type=str)
+    multiline_command = attr.ib(default='', validator=attr.validators.instance_of(str))
 
     # the character which terminated the multiline command, if there was one
-    terminator = attr.ib(default='', validator=attr.validators.instance_of(str), type=str)
+    terminator = attr.ib(default='', validator=attr.validators.instance_of(str))
 
     # characters appearing after the terminator but before output redirection, if any
-    suffix = attr.ib(default='', validator=attr.validators.instance_of(str), type=str)
+    suffix = attr.ib(default='', validator=attr.validators.instance_of(str))
 
     # if output was piped to a shell command, the shell command as a list of tokens
-    pipe_to = attr.ib(default=attr.Factory(list), validator=attr.validators.instance_of(list), type=List[str])
+    pipe_to = attr.ib(default=attr.Factory(list), validator=attr.validators.instance_of(list))
 
     # if output was redirected, the redirection token, i.e. '>>'
-    output = attr.ib(default='', validator=attr.validators.instance_of(str), type=str)
+    output = attr.ib(default='', validator=attr.validators.instance_of(str))
 
     # if output was redirected, the destination file
-    output_to = attr.ib(default='', validator=attr.validators.instance_of(str), type=str)
+    output_to = attr.ib(default='', validator=attr.validators.instance_of(str))
 
     def __new__(cls, value: object, *pos_args, **kw_args):
         """Create a new instance of Statement.
diff --git a/setup.py b/setup.py
index 53645eff..2947c2ea 100755
--- a/setup.py
+++ b/setup.py
@@ -61,7 +61,7 @@ Topic :: Software Development :: Libraries :: Python Modules
 
 SETUP_REQUIRES = ['setuptools_scm']
 
-INSTALL_REQUIRES = ['pyperclip >= 1.5.27', 'colorama', 'attrs']
+INSTALL_REQUIRES = ['pyperclip >= 1.5.27', 'colorama', 'attrs >= 16.3.0']
 
 EXTRAS_REQUIRE = {
     # Windows also requires pyreadline to ensure tab completion works