Drop Python 2.6 support

[tseaver]

Per Nick Coghlan's blog post.

tl;dr: folks still running Python 2.6 can't reasonably expect to be updating to latest-and-greatest of everything else, especially if they aren't paying for it with blood or treasure.

[digitalresistor]

For 1.7 we could totally just drop it.

[mmerickel]

I have no problem dropping 2.6 considering it was EOL 2 years ago. The only argument against that I know are 1) according to @dstufft's numbers there are still tons of installations of 2.6 using PyPI 2) it's not hard to support - at least so far.

Next question: soft or hard drop? The current setup.py raises a RuntimeError on < 2.6 because Pyramid uses things like the with statement that don't work on 2.5 whereas 2.6 feels more like "it may work or it may not, but we aren't testing it anymore".

[mmerickel]

Actually I think the with statement is 2.5+... Maybe byte strings are a better example. Point remains.

[digitalresistor]

We should remove it from setup.py, besides that, let's keep testing on Python 2.6 until we decide it's time to drop it.

[mmerickel]

Sorry what do you mean "remove it from setup.py" ? The trove classifier? A hard fail?

[digitalresistor]

Remove it from the trove classifier.

[tseaver]

ISTM that dropping it from tox/Travis should go hand-in-hand with dropping it from Trove: we get quicker turnarounds for builds, plus we can start using 2.7-only features / syntax, e.g. improved unittest assertions, set literals, dict comprehensions, etc. I'm +0 to dropping it for 1.7 (since we haven't deprecated it ahead) and +1 for whatever release comes afterward (1.8 or 2.0).

[dstufft]

I personally think Pyramid can probably ditch Python 2.6, but I'll let y'all make that decision. However, data is cool, so here is the downloads for Pyramid from 2016-02-22:

python_version	download_count
2.7	1855
3.4	270
3.5	175
2.6	123
Unknown	75
3.3	67
3.2	8

[dstufft]

I also think you can ditch support for Python <3.4 as well, and make it just 2.7, and 3.4+. In general the web world seems to be the best at getting to newer versions of Python quicker.

[stevepiercy]

I would very much like to drop 3.3 because it will make writing docs to transition from setuptools to pip a wee bit easier, due to pip being available by default in most installations of Python 3.4 or later.

[digitalresistor]

Wish Github had a way to vote on things:

Thumbsup on this comment means remove Python 2.6 for Pyramid 1.7
Thumbsdown on this comment means deprecate Python 2.6 and remove at a later time

[digitalresistor]

Thumbsup on this comment means remove Python 3.3 for Pyramid 1.7
Thumbsdown on this comment means deprecate Python 3.3 and remove at a later time

[stevepiercy]

Python 2.6 was EOLed Oct 29, 2013. We let that one slip by.
https://www.python.org/dev/peps/pep-0361/

Python 3.3 is EOLed for September 2017. I vote a definitive Pyramid 1.8 for its removal, instead of "later time".
https://www.python.org/dev/peps/pep-0398/#lifespan

[digitalresistor]

I mentioned later time so that we could have a discussion around it. I am okay with 1.8 being that time.

[mmerickel]

One very subtle concern I have about dropping 2.6 is that it currently acts as a very solid sanity check against bugs in older versions of 2.7. For example the hmac.compare_digest which was introduced in 2.7.11 or something. 2.6 exercises the codepath that older versions of 2.7 will execute, keeping us honest. It's a real issue with this 2.7 series introducing new features in bugfix releases versus any other version.