Drop support for Python 2

[mmerickel]

• The PSF will stop supporting Python 2.7 in 2020.

• Many other projects [1] are dropping support for Python 2 around 2018. While these are scientific projects, it remains a trend.

• Django [2] is dropping support for Python 2 in Django 2.0 which is due to be released in Dec 2017. They are also releasing Django 1.11 LTS with 2.x support through 2020.

I propose that Pyramid 2.0 would be Python 3+ only. Right now it appears as if it's far enough out that it will fall into a reasonable timeline for this to happen. We could also consider committing to a version of Pyramid (1.10 or 1.11 or whatever) that we guarantee support for through 2020 with warnings about pinning to < 2.0 to avoid getting a 3.x only Pyramid.

I personally maintain large Python 2 projects at $work, and I know many other people using Pyramid are 2.x only and so I just want to start the discussion early so that we can plan for an eventual removal. This is only a proposal right now but I do think we should consider removing it at some point such that we can begin to embrace more 3.x-only features in the codebase and ease maintenance going forward.

[1] http://www.python3statement.org/
[2] https://www.djangoproject.com/weblog/2015/jun/25/roadmap/

[ergo]

I'm all for it - I wouldn't worry too much about 2020 drop - it is highly likely that Red Hat will step in and maintain it - they still have it in RHEL so someone "has to" maintain it.

[ergo]

I'm all for it - I wouldn't worry too much about 2020 drop - it is highly likely that Red Hat will step in and maintain it - they still have it in RHEL so someone "has to" maintain it.

[Natim]

I just finished that work for Kinto, if you want it I can start something maybe for a 2.0 release?

Kinto/kinto#1050

[Natim]

I just finished that work for Kinto, if you want it I can start something maybe for a 2.0 release?

Kinto/kinto#1050

[Natim]

As well as dropping support for Python 2.7 I would also like to:

• Make sure the code is pep8 compliant.
• Use mock for some tests that needs it.

[Natim]

As well as dropping support for Python 2.7 I would also like to:

• Make sure the code is pep8 compliant.
• Use mock for some tests that needs it.

[mmerickel]

As well as dropping support for Python 2.7 I would also like to:

@Natim I think #2362 or a new issue linked to there would be better to ensure this comment doesn't get lost.

[mmerickel]

As well as dropping support for Python 2.7 I would also like to:

@Natim I think #2362 or a new issue linked to there would be better to ensure this comment doesn't get lost.

[mmerickel]

I think tentatively we should designate 1.10 as an LTS release with guaranteed support for Python 2 until January 1 2020. We would then remove all Python 2 shims in Pyramid 2.x (which has no current timeline) explicitly saying that Pyramid 2.x would no longer run on Python 2.

@tseaver Do you have anything to say about dropping Python 2 support and / or explicitly breaking Python 2? At some point I think it should be done so that we can easily embrace Python 3 features like non-comment-based type annotations, f-strings, etc but I don't have a good feeling on how to go about that and how aggressively it could be done without hurting the community.

[mmerickel]

I think tentatively we should designate 1.10 as an LTS release with guaranteed support for Python 2 until January 1 2020. We would then remove all Python 2 shims in Pyramid 2.x (which has no current timeline) explicitly saying that Pyramid 2.x would no longer run on Python 2.

@tseaver Do you have anything to say about dropping Python 2 support and / or explicitly breaking Python 2? At some point I think it should be done so that we can easily embrace Python 3 features like non-comment-based type annotations, f-strings, etc but I don't have a good feeling on how to go about that and how aggressively it could be done without hurting the community.

[tseaver]

I'm +1 on dropping support for Python2 after its EOL (2020-01-01), or even in the run-up to it (last quarter of 2019, maybe?)

I'm +0 on an "LTS" release promising to support Python2 until then: do we have a roadmap for features not related to Python3-only changes? If so, would such features need to be ported between a presumably-Python3-only master branch and a "straddling" 1.10 branch until the EOL? I don't have a sense for the relative value of a cleaner Python3-embracing master versus the porting effort if we do the branching early.

[tseaver]

I'm +1 on dropping support for Python2 after its EOL (2020-01-01), or even in the run-up to it (last quarter of 2019, maybe?)

I'm +0 on an "LTS" release promising to support Python2 until then: do we have a roadmap for features not related to Python3-only changes? If so, would such features need to be ported between a presumably-Python3-only master branch and a "straddling" 1.10 branch until the EOL? I don't have a sense for the relative value of a cleaner Python3-embracing master versus the porting effort if we do the branching early.

[bertjwregeer]

What that means is that we continue to do bug fixes to 1.10 until 2020, even if we end up releasing two or more new Pyramid versions in the mean time (2.0 and 2.1) since we tend to only support the last 2 releases. (For example currently we support and do back ports for bug fixes to 1.8 and 1.9).

I'd be okay on an LTS at 1.10 for Py2 with a drop dead date of 2020. I don't think it will be a big effort.

I am also okay with no longer providing new features to users of Python 2 instead making those features part of Pyramid 2.x only and thus Py3 only.

[bertjwregeer]

What that means is that we continue to do bug fixes to 1.10 until 2020, even if we end up releasing two or more new Pyramid versions in the mean time (2.0 and 2.1) since we tend to only support the last 2 releases. (For example currently we support and do back ports for bug fixes to 1.8 and 1.9).

I'd be okay on an LTS at 1.10 for Py2 with a drop dead date of 2020. I don't think it will be a big effort.

I am also okay with no longer providing new features to users of Python 2 instead making those features part of Pyramid 2.x only and thus Py3 only.

[mmerickel]

The main goals here would be:

1. To declare / guarantee to the community that 1.10 or just 1.x or something would support Python 2 at least until EOL. This means bugfixes plus any backported features people felt like making but with no explicit requirements to backport any new features.

2. To make a clean break so there is no doubt when we killed Python 2 support... This is partially for my benefit because when we dropped Python 2.6 it was done a little haphazardly and I rejected some Python 2.7 syntax at the time because even though we had dropped support I still wasn't comfortable explicitly breaking 2.6 by adopting 2.7+ only features.

New feature development would be done on master (2.x) and would drop all Python 2 shims, travis/appveyor CI, etc.

As far as a roadmap for new features... that list is pretty short and probably a separate discussion!

[mmerickel]

The main goals here would be:

1. To declare / guarantee to the community that 1.10 or just 1.x or something would support Python 2 at least until EOL. This means bugfixes plus any backported features people felt like making but with no explicit requirements to backport any new features.

2. To make a clean break so there is no doubt when we killed Python 2 support... This is partially for my benefit because when we dropped Python 2.6 it was done a little haphazardly and I rejected some Python 2.7 syntax at the time because even though we had dropped support I still wasn't comfortable explicitly breaking 2.6 by adopting 2.7+ only features.

New feature development would be done on master (2.x) and would drop all Python 2 shims, travis/appveyor CI, etc.

As far as a roadmap for new features... that list is pretty short and probably a separate discussion!

[Natim]

I agree with @mmerickel that dropping Python 2 support will allow us to cleanup the codebase, and adopt new Python 3 best practices

[Natim]

I agree with @mmerickel that dropping Python 2 support will allow us to cleanup the codebase, and adopt new Python 3 best practices

[stevepiercy]

@tseaver I think @mmerickel already answered your question as far as what would be done, but here's the Pyramid 2.0 possible feature list.

[stevepiercy]

@tseaver I think @mmerickel already answered your question as far as what would be done, but here's the Pyramid 2.0 possible feature list.