Issue 214 legacy python2

[Querela]

Addresses #214

• added legacy_python [no|yes] cookiecutter switch
• updates setup.py, c extension code, tox.ini
  • set python2.7 as legacy
  • remove python3.5 completely (users can add it themselves later on)
• removes old from __future__ import ... if python2 is disabled, from setup.py only - ci/bootstrap.py can still be called with python2 even if project targets python3 only
• added tests for cookiecutter (WIP? - should they be reduced to improve test run time)
• add/update documentation to readme

And I agree with the LICENSE the project is under.

[ionelmc]

Looking good, just few nits to fix. I think we can also simply drop python3.5 from everywhere, I don't expect anyone to need it considering how easy is to upgrade a minor py3 version.

[Querela]

Looking good, just few nits to fix. I think we can also simply drop python3.5 from everywhere, I don't expect anyone to need it considering how easy is to upgrade a minor py3 version.

Ahh. You mean if users choose legacy_python (Py2.7 + Py3.5 + newer)? Or is there some other location were I forgot to remove it when choosing only new Python >= 3.6?

[ionelmc]

I mean 3.5 is not legacy. It's simply something nobody cares about. Even pypy3 is at least 3.6. We can just remove it completely.

[Querela]

I mean 3.5 is not legacy. It's simply something nobody cares about. Even pypy3 is at least 3.6. We can just remove it completely.

Oh? I know of many older linux distros (e. g. *Debian Stretch*) that only ship with python3.5 at most. That's not great and I often use Anaconda to get the latest version. But that might be an use-case. Otherwise, many fancy features are introduced in python3.6 (typings I think), so yea.

If so, should I also remove py35 from the test scripts (test.sh), too?

The changes can be seen here: https://github.com/Querela/cookiecutter-pylibrary/compare/issue-214-legacy-python2...Querela:issue-214-legacy-python2-remove-py35?expand=1 (I can push them in this pull request if required but I would keep python3.5 as legacy version.)

[ionelmc]

Mkay then lets lower the python_requires to >=3.5 then.

[Querela]

Mkay then lets lower the python_requires to >=3.5 then.

I might have misunderstood something. I thought you wanted to remove python3.5 from the legacy versions? Currently in this pull request it is like this:

• with legacy python: >=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*, !=3.4.*
• only python3: >=3.6

If users want to create software for legacy python versions, like python2.7 they also can do so for python3.5 and upwards. Deleting 3 locations where python3.5/py35 is mentioned, should be easy with searching, so I wanted to keep them in there. The other option (legacy_python=="no"), they only have the choice of non-depreciated/in-support python versions, currently python3.6 upwards.

[ionelmc]

I mean if you think it's valuable to still keep 3.5 for a while we can do it but then if legacy_python=no still keep 3.5 around for simplicity sake (avoid all sorts of weird branches in templates).

But it's a library template after all, so users are expected to have 3.6+ pythons around ... so I'm not really sure if the debian stretch argument is really that solid :)

[Querela]

Ahh, no, legacy_python=="no" (the default) starts with python3.6.

[Querela]

But I can just push the changes that remove python3.5 completely (from the legacy versions). My thoughts were just, that if developers want to include python2.7, they probably also include python3.5 in their list, so I wanted to keep it there, just in case. (But added those later should also not be that much more work for users.) New project probably only want to start with python3.6 anyway, so there it does not matter.

[ionelmc]

Very well, merged now, thanks.