Drop support for Python 2.7 with next minor release

[csadorf]

• Used AEP template from AEP 0
• Status is submitted
• Added type & status labels to PR
• Added AEP to README.md
• Provided github handles for authors

[csadorf]

This AEP is to be interpreted as an alternative to this AEP.

[ltalirz]

Hehe, should I now request changes on this? ;-)

[csadorf]

Hehe, should I now request changes on this? ;-)

I actually realized that it wouldn't be too much work to write the AEP for both alternatives and I found it a little easier to argue for this variant TBH. So I think we should have a quick discussion on which variant is generally preferred and then work out the details on that.

[sphuber]

Just for my understanding of the protocol: what determines the number of the AEP? Why 300? When it will be finally approved, just before merging will it take the next available subsequent number, i.e. 001? Or are they not supposed to be sequential?

[kjappelbaum]

I feel it should be consistent with https://www.python.org/dev/peps/pep-0001/#pep-editor-responsibilities-workflow. Though I think sequential would make most sense.

Assign a PEP number (almost always just the next available number, but sometimes it's a special/joke number, like 666 or 3141). (Clarification: For Python 3, numbers in the 3000s were used for Py3k-specific proposals. But now that all new features go into Python 3 only, the process is back to using numbers in the 100s again. Remember that numbers below 100 are meta-PEPs.

[ltalirz]

just before merging will it take the next available subsequent number, i.e. 001

yes, that was the idea + the status will be changed to "active".

If changed the branch protection rules such that further pushes to the branch don't dismiss an approval.
I think that's the practical solution - let me know if you would prefer another way.

[sphuber]

So @csadorf did you chose 300 to keep 0-100 for meta and to indicate that this marks the start of python 3 only? (Since we probably won't be doing PEP's for py2 branches)

[csadorf]

So @csadorf did you chose 300 to keep 0-100 for meta and to indicate that this marks the start of python 3 only? (Since we probably won't be doing PEP's for py2 branches)

I just chose it, because it seemed to fit and thought I got approval from @ltalirz , I guess that was a misunderstanding.

[csadorf]

I think we should keep the number until next Tuesday for discussion purposes and then we can reassign one if we feel strongly about it before merging.

[csadorf]

So far there have been no comments on the mailing list. Anything else that would need to be addressed prior to accepting this tomorrow?

[sphuber]

I guess just to decide the numbering, but other than that I think this is good to go. I already prepared a PR to actually drop the support and clean up all the code. Dominik already gave it a pass, but it would be good to have others give a look as well, as well as try and go through the code base itself to see if I missed something. Then I want to release v1.0.1 with the current changes in develop and then merge the PR in develop, which will then become v1.1. I am also in far stage of moving CI to GitHub and with that done, we are ready for the coding week

[csadorf]

I guess just to decide the numbering, but other than that I think this is good to go.

@ltalirz Since you are championing this AEP, are you going to take charge of that?

[ltalirz]

Right, then as the "AEP editor" I am assigning number 001
@csadorf could you please update the branch in your fork?

@sphuber @greschd We would need also one more approval to merge

[greschd]

I don't think my approval counts here 😄

[sphuber]

Alle trossen los!

[csadorf]

@ltalirz Should be ready for merge.

[ltalirz]

Aaand we have our first AEP merged. Thanks a bunch @csadorf !