Support for Python 2.7 and 3.4

[provinzkraut]

Python 3.4 is EOL and 2.7 will be next year. Are there plans to drop support for these versions?

Dropping 2.7 would have the benefit of getting to clean up the codebase a fair amount and when dropping 3.4, type hints could eventually be added at some point without the need to use additional comments.

[oz123]

I would very much like to see Python2.7 dropped from the current bottle code as it would simplify significant portion of the code. As for type hints I am still not sure it's the right thing for a micro webframework.

[defnull]

We can phase out support for old Python versions as soon as these reach EOL, but not before that.

For master this means: We can stop testing against dead python versions and start accepting pull requests that only work with never versions. Pull requests that simplify code but do not otherwise change the behavior are always welcomed, so the 2.x EOL will be an opportunity to remove A LOT of compatibility code and workarounds. (But please do not try to do this in a giant patch that fixes code and tests at the same time. There would be no way to verify it, then). For releases this means: Testing against dead python versions when writing or back-porting bug-fixes is still encouraged, but no longer required. We do not want to break compatibility if not absolutely necessary. The Linux distribution maintainers will thank us. I'll suspect that 2.7 will be supported by some enterprise distributions way beyond the official EOL date, and they should have the opportunity to stay on an old bottle release and still get their bug-fixes merged.

[n3h3m]

We can phase out support for old Python versions as soon as these reach EOL, but not before that.

For master this means: We can stop testing against dead python versions and start accepting pull requests that only work with never versions. Pull requests that simplify code but do not otherwise change the behavior are always welcomed, so the 2.x EOL will be an opportunity to remove A LOT of compatibility code and workarounds. (But please do not try to do this in a giant patch that fixes code and tests at the same time. There would be no way to verify it, then). For releases this means: Testing against dead python versions when writing or back-porting bug-fixes is still encouraged, but no longer required. We do not want to break compatibility if not absolutely necessary. The Linux distribution maintainers will thank us. I'll suspect that 2.7 will be supported by some enterprise distributions way beyond the official EOL date, and they should have the opportunity to stay on an old bottle release and still get their bug-fixes merged.

This is such a matured approach. I am lurking through similar threads on various projects. I hate to see communities are rushing to 'kill' or 'drop' Python 2.7 support. What they don't realize is, instead of releasing a giant PR to drop support for 2.7, but by making new releases with newer language features, the framework would eventually naturally stop working in Python 2.7.

[henryh9n]

Looks like there's been some progress with this in #1193. Seems stale now tho. Can give you a hand if needed, looking for smt to do on my spare time