Remove Python 3.2 support

[digitalresistor]

This removes Python 3.2 support from the testing path, and from setup.py. At this point testing it becomes more difficult because pip no longer installs/runs under Python 3.2, and tox pulls in the latest version of pip.

[digitalresistor]

Closes #2255

Not sure if we want to backport this to 1.5/1.6, but if we don't we need to figure out how install an older version of pip in the Python 3.2 tox environment.

[stevepiercy]

This PR also needs to include updates to docs. I'm working on those now.

[stevepiercy]

Docs updated for Pyramid, except for one mention of Waitress running on 3.2+ in docs/glossary.rst.

[stevepiercy]

From https://www.python.org/dev/peps/pep-0392/#lifespan

...security updates (source only) will be released until 5 years after the release of 3.2 final, which will be February 2016.

I think this should definitely be merged into master for Pyramid 1.7 release.

Since docs for 1.6/latest is the version most hit from search engine results, and pip is where everyone is headed, I'd say backport to 1.6.

For 1.5, I'd say remove testing for 3.2 to get it to pass, but we leave the docs as is to indicate that it runs on 3.2.

Also for future thought, we might want to declare our plan for support of Python 3.3, which is scheduled to cease receiving security updates in September 2017:
https://www.python.org/dev/peps/pep-0398/#lifespan

[digitalresistor]

I've added the 1.7 milestone for this. We should definitely add a document somewhere to declare our intentions and how long we will support Python versions. Python 2.6 is kind of a special snowflake, because of CentOS 6.x. It was last released in 2008!!!

[digitalresistor]

@mmerickel I am going to answer your questions on the original ticket here:

pypa/packaging#58

We can use this for Python 3.2 support on Travis, this way we can continue building on travis for 1.5/1.6 branches. Local building becomes a HUGE pain.

[mmerickel]

I'm much less worried about the complexity of building locally for backports. Anyone who is actually stuck building those versions probably has a machine where it's easier to operate in that enivronment. All backports should be tested via travis using such a fix. Any new features belong on master where we drop 3.2 and local testing is not difficult.

[stevepiercy]

Is it OK to merge this PR onto master, or is there something else we need to do or are waiting for?

Here's a statement of support of Python, although I don't know where it should go. It might also be a Pylons Project policy.

Python Support Policy

At the time of each release of Pyramid, each version supports all versions of Python to the end of their lifespans. The end-of-life for a given version of Python is when security updates are no longer released.

• Python 3.2 Lifespan ends February 2016.
• Python 3.3 Lifespan ends September 2017.
• Python 3.4 Lifespan TBD.
• Python 3.5 Lifespan TBD.
• Python 3.6 Lifespan December 2021.

To determine the Python support for a specific release of Pyramid, view its tox.ini file at the root of the repository.

[digitalresistor]

I don't want to merge this myself, but I am a +1 on merging this asap. I'm leaving it to @mmerickel. We need to apply the fix above for the 1.6-branch and 1.5-branch so that we can continue to build Python 3.2 on Travis for those branches.

[mmerickel]

We need to apply the fix above for the 1.6-branch and 1.5-branch so that we can continue to build Python 3.2 on Travis for those branches.

Can you add PRs that build for those branches?

[digitalresistor]

Yes, when I get back Monday. I am currently out at SCALE14X.

[digitalresistor]

#2269 #2270

[stevepiercy]

For "Python Support Policy", how about placing the content here?
http://docs.pylonsproject.org/projects/pyramid/en/latest/narr/upgrading.html#deprecation-and-removal-policy

I also modified the content to point to each branch's tox.ini to find Python support. Much cleaner.

[mmerickel]

@stevepiercy that seems like a logical place.