Django 2.0 Python version support (Python 3.6+ only?)

[Tim Graham]

When I drafted the 1.11 release notes in May, I wrote, "The next major
release, Django 2.0, will only support Python 3.5+."

Our Python version support policy is "Typically, we will support a Python
version up to and including the first Django LTS release whose security
support ends after security support for that version of Python ends."

Python 3.5's EOL is September 2020 which I think is sufficiently close to
Django 1.11's EOL of April 2020 that we could say Django 2.0 is Python
3.6+. The alternative is not to drop Python 3.5 compatibility until Django
2.2 LTS which is supported until April 2022. I don't see much advantage to
that. Any objections?

p.s. There is already a ticket suggesting to take advantage of a Python 3.6
feature:
https://code.djangoproject.com/ticket/27635* - *django.utils.crypto should
use secrets on Python 3.6+

[Florian Apolloner]

Imo we should not drop Python versions overeagerly. After all I do not
wanna compile our own python for djangoproject.com :D Given that Redhat is
on Python 3.4 for the foreseeable future, I'd actually even like to see 3.4
still supported in Django 2.0 unless there is a good reason to drop it.
Fwiw, Ubuntu Trusty which is LTS and still supported also is on Python 3.4.
So unless there are compelling arguments to drop 3.4, lets keep it as long
as it is not too much work.

Either way, I am completely against dropping Python 3.5 now -- lets make
the Django 2.0 migration not more painful than it has to be (ie I do not
want to force people to upgrade existing supported systems just to get the
latest python and therefor Django).

Cheers,
Florian

Post by Tim Graham
When I drafted the 1.11 release notes in May, I wrote, "The next major
release, Django 2.0, will only support Python 3.5+."
Our Python version support policy is "Typically, we will support a Python
version up to and including the first Django LTS release whose security
support ends after security support for that version of Python ends."
Python 3.5's EOL is September 2020 which I think is sufficiently close to
Django 1.11's EOL of April 2020 that we could say Django 2.0 is Python
3.6+. The alternative is not to drop Python 3.5 compatibility until Django
2.2 LTS which is supported until April 2022. I don't see much advantage to
that. Any objections?
p.s. There is already a ticket suggesting to take advantage of a Python
https://code.djangoproject.com/ticket/27635* - *django.utils.crypto
should use secrets on Python 3.6+

[Tim Graham]

Collin raised a fair point in #django-dev that Ubuntu 16.04 bundles Python
3.5. I guess 16.10 will include Python 3.6 -- that will be released before
Django 2.0 in December 2017.

Presumably any Python's we don't drop for 2.0 we will have to support until
the next LTS (which means 2 more years where we can't use any Python 3.6+
features without extra work to support them on 3.4, 3.5), or else we risk
stranding Django users on some Django version like 2.0 or 2.1 where they
could have received security updates for longer if they stayed on on 1.11
LTS. I don't like that situation.

How would you revise our Python support policy?

In my mind, the purpose of LTS is for conservative organizations that don't
want to use the latest Python, Django, etc. Are Red Hat users on Python 3.4
demanding the latest Django? Maybe if Django is more aggressive about
dropping old Pythons, those users will demand newer Pythons.

It's hard to quantify how much extra work it is to support old Python
versions, but besides the overhead of conditional code, dropping old
versions also brings the possibility to use new features in Python. It also
increases the size of build matrices across the entire Django ecosystem
since most packages follow Django's version support.

https://www.djangoproject.com/download/#supported-versions
https://docs.python.org/devguide/#status-of-python-branches

Post by Florian Apolloner
Imo we should not drop Python versions overeagerly. After all I do not
wanna compile our own python for djangoproject.com :D Given that Redhat
is on Python 3.4 for the foreseeable future, I'd actually even like to see
3.4 still supported in Django 2.0 unless there is a good reason to drop it.
Fwiw, Ubuntu Trusty which is LTS and still supported also is on Python 3.4.
So unless there are compelling arguments to drop 3.4, lets keep it as long
as it is not too much work.
Either way, I am completely against dropping Python 3.5 now -- lets make
the Django 2.0 migration not more painful than it has to be (ie I do not
want to force people to upgrade existing supported systems just to get the
latest python and therefor Django).
Cheers,
Florian

Post by Tim Graham
When I drafted the 1.11 release notes in May, I wrote, "The next major
release, Django 2.0, will only support Python 3.5+."
Our Python version support policy is "Typically, we will support a Python
version up to and including the first Django LTS release whose security
support ends after security support for that version of Python ends."
Python 3.5's EOL is September 2020 which I think is sufficiently close to
Django 1.11's EOL of April 2020 that we could say Django 2.0 is Python
3.6+. The alternative is not to drop Python 3.5 compatibility until Django
2.2 LTS which is supported until April 2022. I don't see much advantage to
that. Any objections?
p.s. There is already a ticket suggesting to take advantage of a Python
https://code.djangoproject.com/ticket/27635* - *django.utils.crypto
should use secrets on Python 3.6+

[Michael Manfre]

Post by Tim Graham
Collin raised a fair point in #django-dev that Ubuntu 16.04 bundles Python
3.5. I guess 16.10 will include Python 3.6 -- that will be released before
Django 2.0 in December 2017.
Presumably any Python's we don't drop for 2.0 we will have to support
until the next LTS (which means 2 more years where we can't use any Python
3.6+ features without extra work to support them on 3.4, 3.5), or else we
risk stranding Django users on some Django version like 2.0 or 2.1 where
they could have received security updates for longer if they stayed on on
1.11 LTS. I don't like that situation.
How would you revise our Python support policy?

I don't think Django should support versions of Python longer than Python
is willing to support them. If this means dropping support for a version of
Python in a non-LTS, then we should do that. As long as it is sufficiently
documented, users will be able to make an informed decision about whether
to stay on the previous LTS for longer Python version support, or move on
to our non-LTS releases to reap the rewards of the newer Django version.
Regardless what they choose, when they end up on the next LTS, they would
have likely updated Django and Python independently along the way.

Post by Tim Graham
In my mind, the purpose of LTS is for conservative organizations that
don't want to use the latest Python, Django, etc. Are Red Hat users on
Python 3.4 demanding the latest Django? Maybe if Django is more aggressive
about dropping old Pythons, those users will demand newer Pythons.

At the organizations I've worked at, the purpose of LTS was to allow them
to defer migrating versions for a few years, and not to avoid using the
latest version now. They would jump on to an LTS release immediately if it
lined up with their planning.

If Red Hat users will be stuck on 3.4, then I feel the burden for
supporting it (backporting security fixes) should fall on Red Hat, not
Django. We should make it as easy as possible for them to do so (e.g.
pre-notification), but not by adding more support burden (conditional code,
build matricies, etc.) to Django or preventing us from using newer features
from Python.

Regards,
Michael Manfre

[Tim Graham]

I'm okay with keeping Python 3.5 support around. I agree it would be a bit
impractical to release Django 2.0 in December without being able to run it
on the most recent Ubuntu LTS.

If we dropped Python 3.5 support after Django 2.1 that would give Django
(2.1) support until December 2019 (or April 2020 if you had stuck with 1.11
LTS). Hopefully most Ubuntu LTS users would be migrated to 18.04 by then
and whatever Python is included there. I guess we'll evaluate it then.

Thanks for the feedback!

Post by Michael Manfre

Post by Tim Graham
Collin raised a fair point in #django-dev that Ubuntu 16.04 bundles
Python 3.5. I guess 16.10 will include Python 3.6 -- that will be released
before Django 2.0 in December 2017.
Presumably any Python's we don't drop for 2.0 we will have to support
until the next LTS (which means 2 more years where we can't use any Python
3.6+ features without extra work to support them on 3.4, 3.5), or else we
risk stranding Django users on some Django version like 2.0 or 2.1 where
they could have received security updates for longer if they stayed on on
1.11 LTS. I don't like that situation.
How would you revise our Python support policy?

I don't think Django should support versions of Python longer than Python
is willing to support them. If this means dropping support for a version of
Python in a non-LTS, then we should do that. As long as it is sufficiently
documented, users will be able to make an informed decision about whether
to stay on the previous LTS for longer Python version support, or move on
to our non-LTS releases to reap the rewards of the newer Django version.
Regardless what they choose, when they end up on the next LTS, they would
have likely updated Django and Python independently along the way.

Post by Tim Graham
In my mind, the purpose of LTS is for conservative organizations that
don't want to use the latest Python, Django, etc. Are Red Hat users on
Python 3.4 demanding the latest Django? Maybe if Django is more aggressive
about dropping old Pythons, those users will demand newer Pythons.

At the organizations I've worked at, the purpose of LTS was to allow them
to defer migrating versions for a few years, and not to avoid using the
latest version now. They would jump on to an LTS release immediately if it
lined up with their planning.
If Red Hat users will be stuck on 3.4, then I feel the burden for
supporting it (backporting security fixes) should fall on Red Hat, not
Django. We should make it as easy as possible for them to do so (e.g.
pre-notification), but not by adding more support burden (conditional code,
build matricies, etc.) to Django or preventing us from using newer features
from Python.
Regards,
Michael Manfre

[Matthias welp]

I won't mind dropping support for Python versions that are not supported up
to the end of the support period of the next LTS (2.2 in this case). If you
want to use long-term stability and/or support for current Python versions,
you should use the current django LTS version, which will be 1.11. I am
perfectly fine with django dropping support for a python version that won't
be supported for over 1 1/2 years of that (major) versions support cycle.

Noting that python 2.x also has an EOL in 2020, this one being half a year
earlier (March 16th vs September 13th), will django 2.0 drop python 2.7
support, or will the 2.x series continue support for 2.7? I cant really
find definite docs on that.
(https://www.djangoproject.com/weblog/2015/jun/25/roadmap/ talks about it
but is not completely clear)

If django drops 2.7 for django 2.x, a lot of code will probably be
reworked, and seeing the 3.6 features I would love to see those available
directly while removing/refactoring the compat-layer. e.g. f-strings
instead of "{}".format or %-formatting, as it is less prone to random bugs
like https://code.djangoproject.com/ticket/6343 .


-Matthias

Post by Florian Apolloner
Imo we should not drop Python versions overeagerly. After all I do not
wanna compile our own python for djangoproject.com :D Given that Redhat
is on Python 3.4 for the foreseeable future, I'd actually even like to see
3.4 still supported in Django 2.0 unless there is a good reason to drop it.
Fwiw, Ubuntu Trusty which is LTS and still supported also is on Python 3.4.
So unless there are compelling arguments to drop 3.4, lets keep it as long
as it is not too much work.
Either way, I am completely against dropping Python 3.5 now -- lets make
the Django 2.0 migration not more painful than it has to be (ie I do not
want to force people to upgrade existing supported systems just to get the
latest python and therefor Django).
Cheers,
Florian

Post by Tim Graham
When I drafted the 1.11 release notes in May, I wrote, "The next major
release, Django 2.0, will only support Python 3.5+."
Our Python version support policy is "Typically, we will support a Python
version up to and including the first Django LTS release whose security
support ends after security support for that version of Python ends."
Python 3.5's EOL is September 2020 which I think is sufficiently close to
Django 1.11's EOL of April 2020 that we could say Django 2.0 is Python
3.6+. The alternative is not to drop Python 3.5 compatibility until Django
2.2 LTS which is supported until April 2022. I don't see much advantage to
that. Any objections?
p.s. There is already a ticket suggesting to take advantage of a Python
https://code.djangoproject.com/ticket/27635* - *django.utils.crypto
should use secrets on Python 3.6+

--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/
msgid/django-developers/f1da2b09-0309-46e6-9a7c-
75ea9cd6f91b%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/f1da2b09-0309-46e6-9a7c-75ea9cd6f91b%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

[Tim Graham]

Yes, Django 1.11 is the last version to support Python 2.7. This is
documented in the 1.11 release notes, in
https://www.djangoproject.com/download/#supported-versions, and elsewhere.

Post by Matthias welp
I won't mind dropping support for Python versions that are not supported
up to the end of the support period of the next LTS (2.2 in this case). If
you want to use long-term stability and/or support for current Python
versions, you should use the current django LTS version, which will be
1.11. I am perfectly fine with django dropping support for a python version
that won't be supported for over 1 1/2 years of that (major) versions
support cycle.
Noting that python 2.x also has an EOL in 2020, this one being half a year
earlier (March 16th vs September 13th), will django 2.0 drop python 2.7
support, or will the 2.x series continue support for 2.7? I cant really
find definite docs on that.
(https://www.djangoproject.com/weblog/2015/jun/25/roadmap/ talks about it
but is not completely clear)
If django drops 2.7 for django 2.x, a lot of code will probably be
reworked, and seeing the 3.6 features I would love to see those available
directly while removing/refactoring the compat-layer. e.g. f-strings
instead of "{}".format or %-formatting, as it is less prone to random
bugs like https://code.djangoproject.com/ticket/6343 .
-Matthias

Post by Florian Apolloner
Imo we should not drop Python versions overeagerly. After all I do not
wanna compile our own python for djangoproject.com :D Given that Redhat
is on Python 3.4 for the foreseeable future, I'd actually even like to see
3.4 still supported in Django 2.0 unless there is a good reason to drop it.
Fwiw, Ubuntu Trusty which is LTS and still supported also is on Python 3.4.
So unless there are compelling arguments to drop 3.4, lets keep it as long
as it is not too much work.
Either way, I am completely against dropping Python 3.5 now -- lets make
the Django 2.0 migration not more painful than it has to be (ie I do not
want to force people to upgrade existing supported systems just to get the
latest python and therefor Django).
Cheers,
Florian

Post by Tim Graham
When I drafted the 1.11 release notes in May, I wrote, "The next major
release, Django 2.0, will only support Python 3.5+."
Our Python version support policy is "Typically, we will support a
Python version up to and including the first Django LTS release whose
security support ends after security support for that version of Python
ends."
Python 3.5's EOL is September 2020 which I think is sufficiently close
to Django 1.11's EOL of April 2020 that we could say Django 2.0 is Python
3.6+. The alternative is not to drop Python 3.5 compatibility until Django
2.2 LTS which is supported until April 2022. I don't see much advantage to
that. Any objections?
p.s. There is already a ticket suggesting to take advantage of a Python
https://code.djangoproject.com/ticket/27635* - *django.utils.crypto
should use secrets on Python 3.6+

--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an
<javascript:>.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/f1da2b09-0309-46e6-9a7c-75ea9cd6f91b%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/f1da2b09-0309-46e6-9a7c-75ea9cd6f91b%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

[Florian Apolloner]

Mhm, just thought about the fact that this means we are also dropping
support for PyPy and Jython -- not sure about the Jyton usage, but loosing
PyPy sounds sad, how far along are there python 3 efforts? It looks like it
is/was close to 3.3 according to
https://morepypy.blogspot.co.at/2016/08/pypy-gets-funding-from-mozilla-for.html

Cheers,
Florian

Post by Tim Graham
Yes, Django 1.11 is the last version to support Python 2.7. This is
documented in the 1.11 release notes, in
https://www.djangoproject.com/download/#supported-versions, and elsewhere.

Post by Matthias welp
I won't mind dropping support for Python versions that are not supported
up to the end of the support period of the next LTS (2.2 in this case). If
you want to use long-term stability and/or support for current Python
versions, you should use the current django LTS version, which will be
1.11. I am perfectly fine with django dropping support for a python version
that won't be supported for over 1 1/2 years of that (major) versions
support cycle.
Noting that python 2.x also has an EOL in 2020, this one being half a
year earlier (March 16th vs September 13th), will django 2.0 drop python
2.7 support, or will the 2.x series continue support for 2.7? I cant really
find definite docs on that.
(https://www.djangoproject.com/weblog/2015/jun/25/roadmap/ talks about
it but is not completely clear)
If django drops 2.7 for django 2.x, a lot of code will probably be
reworked, and seeing the 3.6 features I would love to see those available
directly while removing/refactoring the compat-layer. e.g. f-strings
instead of "{}".format or %-formatting, as it is less prone to random
bugs like https://code.djangoproject.com/ticket/6343 .
-Matthias

Post by Florian Apolloner
Imo we should not drop Python versions overeagerly. After all I do not
wanna compile our own python for djangoproject.com :D Given that Redhat
is on Python 3.4 for the foreseeable future, I'd actually even like to see
3.4 still supported in Django 2.0 unless there is a good reason to drop it.
Fwiw, Ubuntu Trusty which is LTS and still supported also is on Python 3.4.
So unless there are compelling arguments to drop 3.4, lets keep it as long
as it is not too much work.
Either way, I am completely against dropping Python 3.5 now -- lets make
the Django 2.0 migration not more painful than it has to be (ie I do not
want to force people to upgrade existing supported systems just to get the
latest python and therefor Django).
Cheers,
Florian

Post by Tim Graham
When I drafted the 1.11 release notes in May, I wrote, "The next major
release, Django 2.0, will only support Python 3.5+."
Our Python version support policy is "Typically, we will support a
Python version up to and including the first Django LTS release whose
security support ends after security support for that version of Python
ends."
Python 3.5's EOL is September 2020 which I think is sufficiently close
to Django 1.11's EOL of April 2020 that we could say Django 2.0 is Python
3.6+. The alternative is not to drop Python 3.5 compatibility until Django
2.2 LTS which is supported until April 2022. I don't see much advantage to
that. Any objections?
p.s. There is already a ticket suggesting to take advantage of a Python
https://code.djangoproject.com/ticket/27635* - *django.utils.crypto
should use secrets on Python 3.6+

--
You received this message because you are subscribed to the Google
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/f1da2b09-0309-46e6-9a7c-75ea9cd6f91b%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/f1da2b09-0309-46e6-9a7c-75ea9cd6f91b%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

[Tim Graham]

August 2016: PyPy gets funding from Mozilla for Python 3.5 support
"Within the next year, we plan to use the money to pay four core PyPy
developers half-time to work on the missing features and on some of the big
performance and cpyext issues. This should speed up the progress of
catching up with Python 3.x significantly. "
https://morepypy.blogspot.com/2016/08/pypy-gets-funding-from-mozilla-for.html

According to http://pypy.org/py3donate.html, it seems that anyone who cares
can donate to the effort of porting PyPy to Python 3. Django 1.11/Python 2
will be supported until 2020 anyway.

Post by Florian Apolloner
Mhm, just thought about the fact that this means we are also dropping
support for PyPy and Jython -- not sure about the Jyton usage, but loosing
PyPy sounds sad, how far along are there python 3 efforts? It looks like it
is/was close to 3.3 according to
https://morepypy.blogspot.co.at/2016/08/pypy-gets-funding-from-mozilla-for.html
Cheers,
Florian

Post by Tim Graham
Yes, Django 1.11 is the last version to support Python 2.7. This is
documented in the 1.11 release notes, in
https://www.djangoproject.com/download/#supported-versions, and elsewhere.

Post by Matthias welp
I won't mind dropping support for Python versions that are not supported
up to the end of the support period of the next LTS (2.2 in this case). If
you want to use long-term stability and/or support for current Python
versions, you should use the current django LTS version, which will be
1.11. I am perfectly fine with django dropping support for a python version
that won't be supported for over 1 1/2 years of that (major) versions
support cycle.
Noting that python 2.x also has an EOL in 2020, this one being half a
year earlier (March 16th vs September 13th), will django 2.0 drop
python 2.7 support, or will the 2.x series continue support for 2.7? I cant
really find definite docs on that.
(https://www.djangoproject.com/weblog/2015/jun/25/roadmap/ talks about
it but is not completely clear)
If django drops 2.7 for django 2.x, a lot of code will probably be
reworked, and seeing the 3.6 features I would love to see those available
directly while removing/refactoring the compat-layer. e.g. f-strings
instead of "{}".format or %-formatting, as it is less prone to random
bugs like https://code.djangoproject.com/ticket/6343 .
-Matthias

Post by Florian Apolloner
Imo we should not drop Python versions overeagerly. After all I do not
wanna compile our own python for djangoproject.com :D Given that
Redhat is on Python 3.4 for the foreseeable future, I'd actually even like
to see 3.4 still supported in Django 2.0 unless there is a good reason to
drop it. Fwiw, Ubuntu Trusty which is LTS and still supported also is on
Python 3.4. So unless there are compelling arguments to drop 3.4, lets keep
it as long as it is not too much work.
Either way, I am completely against dropping Python 3.5 now -- lets
make the Django 2.0 migration not more painful than it has to be (ie I do
not want to force people to upgrade existing supported systems just to get
the latest python and therefor Django).
Cheers,
Florian

Post by Tim Graham
When I drafted the 1.11 release notes in May, I wrote, "The next major
release, Django 2.0, will only support Python 3.5+."
Our Python version support policy is "Typically, we will support a
Python version up to and including the first Django LTS release whose
security support ends after security support for that version of Python
ends."
Python 3.5's EOL is September 2020 which I think is sufficiently close
to Django 1.11's EOL of April 2020 that we could say Django 2.0 is Python
3.6+. The alternative is not to drop Python 3.5 compatibility until Django
2.2 LTS which is supported until April 2022. I don't see much advantage to
that. Any objections?
p.s. There is already a ticket suggesting to take advantage of a
https://code.djangoproject.com/ticket/27635* - *django.utils.crypto
should use secrets on Python 3.6+

--
You received this message because you are subscribed to the Google
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/f1da2b09-0309-46e6-9a7c-75ea9cd6f91b%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/f1da2b09-0309-46e6-9a7c-75ea9cd6f91b%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

[Asif Saifuddin]

Hi,

django 2.0 will be released in december 2017 and ubuntu 18.04 will be
released in april 2018 which will default atleast 3.6, so I think this
should also be taken as consideration while deciding.

Thanks

Post by Tim Graham
August 2016: PyPy gets funding from Mozilla for Python 3.5 support
"Within the next year, we plan to use the money to pay four core PyPy
developers half-time to work on the missing features and on some of the big
performance and cpyext issues. This should speed up the progress of
catching up with Python 3.x significantly. "
https://morepypy.blogspot.com/2016/08/pypy-gets-funding-from-mozilla-for.html
According to http://pypy.org/py3donate.html, it seems that anyone who
cares can donate to the effort of porting PyPy to Python 3. Django
1.11/Python 2 will be supported until 2020 anyway.

Post by Florian Apolloner
Mhm, just thought about the fact that this means we are also dropping
support for PyPy and Jython -- not sure about the Jyton usage, but loosing
PyPy sounds sad, how far along are there python 3 efforts? It looks like it
is/was close to 3.3 according to
https://morepypy.blogspot.co.at/2016/08/pypy-gets-funding-from-mozilla-for.html
Cheers,
Florian

Post by Tim Graham
Yes, Django 1.11 is the last version to support Python 2.7. This is
documented in the 1.11 release notes, in
https://www.djangoproject.com/download/#supported-versions, and elsewhere.

Post by Matthias welp
I won't mind dropping support for Python versions that are not
supported up to the end of the support period of the next LTS (2.2 in this
case). If you want to use long-term stability and/or support for current
Python versions, you should use the current django LTS version, which will
be 1.11. I am perfectly fine with django dropping support for a python
version that won't be supported for over 1 1/2 years of that (major)
versions support cycle.
Noting that python 2.x also has an EOL in 2020, this one being half a
year earlier (March 16th vs September 13th), will django 2.0 drop
python 2.7 support, or will the 2.x series continue support for 2.7? I cant
really find definite docs on that.
(https://www.djangoproject.com/weblog/2015/jun/25/roadmap/ talks about
it but is not completely clear)
If django drops 2.7 for django 2.x, a lot of code will probably be
reworked, and seeing the 3.6 features I would love to see those available
directly while removing/refactoring the compat-layer. e.g. f-strings
instead of "{}".format or %-formatting, as it is less prone to random
bugs like https://code.djangoproject.com/ticket/6343 .
-Matthias

Post by Florian Apolloner
Imo we should not drop Python versions overeagerly. After all I do not
wanna compile our own python for djangoproject.com :D Given that
Redhat is on Python 3.4 for the foreseeable future, I'd actually even like
to see 3.4 still supported in Django 2.0 unless there is a good reason to
drop it. Fwiw, Ubuntu Trusty which is LTS and still supported also is on
Python 3.4. So unless there are compelling arguments to drop 3.4, lets keep
it as long as it is not too much work.
Either way, I am completely against dropping Python 3.5 now -- lets
make the Django 2.0 migration not more painful than it has to be (ie I do
not want to force people to upgrade existing supported systems just to get
the latest python and therefor Django).
Cheers,
Florian

Post by Tim Graham
When I drafted the 1.11 release notes in May, I wrote, "The next
major release, Django 2.0, will only support Python 3.5+."
Our Python version support policy is "Typically, we will support a
Python version up to and including the first Django LTS release whose
security support ends after security support for that version of Python
ends."
Python 3.5's EOL is September 2020 which I think is sufficiently
close to Django 1.11's EOL of April 2020 that we could say Django 2.0 is
Python 3.6+. The alternative is not to drop Python 3.5 compatibility until
Django 2.2 LTS which is supported until April 2022. I don't see much
advantage to that. Any objections?
p.s. There is already a ticket suggesting to take advantage of a
https://code.djangoproject.com/ticket/27635* - *django.utils.crypto
should use secrets on Python 3.6+

--
You received this message because you are subscribed to the Google
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/f1da2b09-0309-46e6-9a7c-75ea9cd6f91b%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/f1da2b09-0309-46e6-9a7c-75ea9cd6f91b%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

[Florian Apolloner]

Hi Asif,

Post by Asif Saifuddin
django 2.0 will be released in december 2017 and ubuntu 18.04 will be
released in april 2018 which will default atleast 3.6, so I think this
should also be taken as consideration while deciding.

What comes out __after__ the release of Django is the least of my concerns.
The more important thing here are the still supported LTS releases and how
disruptive that change would be. OS releases after Django's release are in
general not an issue (aside from new bugs here and there, but that is
nothing anyone can predict).

Cheers,
Florian

['Tom Evans' via Django developers (Contributions to Django itself)]

Post by Asif Saifuddin
Hi,
django 2.0 will be released in december 2017 and ubuntu 18.04 will be
released in april 2018 which will default atleast 3.6, so I think this
should also be taken as consideration while deciding.

I know supporting endless versions of python is not desirable, but
please bear in mind that some of us are in situations where what the
latest release of Ubunutu is not really relevant.

Our organisation uses CentOS 6, which is not EOL until the end of
2020. In CentOS 6, the stock version of python is python 2.6; we go
through special measures (EPEL) to get that up to python 2.7. If we
wanted to make the move to Python 3, we'd be talking about Python 3.4,
again through EPEL.

We have an infrastructure team responsible for provisioning servers,
and it is on their schedule that OS upgrades occur - it is not easy
for us as developers to argue that this team should spend significant
resource to upgrade to a later OS version or to roll custom python
RPMs.

Updating all of our codebase to Python 3 is going to be a pain for us,
it is hard to argue a business need with "Everything stays exactly the
same but is slightly more secure and easier to maintain".
Realistically, when we move to Python 3, it will be because the
supported Django LTS requires it. If we also have to jump through lots
of hoops to get the very latest Python 3 release, it won't make it
easier to argue, it will mean we are more likely to postpone it and
keep using old django versions, particularly on internal intranet
sites.

If there is a way that Python 3.4 support can be maintained without
significant detriment or penalty, this would be greatly appreciated by
those of us running more conservative enterprise distributions.

Cheers

Tom

[Tim Graham]

Tom, I'm not following how Python 3.4 support in Django 2.0 will benefit
you if you want to stick to LTS versions of Django? I think either you or I
have a misunderstanding somewhere. I'll try to recap:

Django 1.11 is the next LTS. It's supported until April 2020 and supports
Python 3.4. The next LTS, Django 2.2 is due in April 2019, after the Python
3.4 end of life in March 2019 -- so I don't think we can justify supporting
Python 3.4 in that LTS unless we decide to base our supported Python policy
on CentOS rather than Python's own support lifecycle. Florian and Daniele
are proposing supporting Python 3.4 for Django 2.0 and/or 2.1. Those
versions have security support ending in April 2019 and December 2019,
respectively. If you want to use Python 3.4 and maximize the time you can
receive Django security updates, stick with 1.11 LTS (April 2020).

Look at these tables if you're in doubt:
https://www.djangoproject.com/download/#supported-versions
https://docs.python.org/devguide/#status-of-python-branches

Post by 'Tom Evans' via Django developers (Contributions to Django itself)

Post by Asif Saifuddin
Hi,
django 2.0 will be released in december 2017 and ubuntu 18.04 will be
released in april 2018 which will default atleast 3.6, so I think this
should also be taken as consideration while deciding.

I know supporting endless versions of python is not desirable, but
please bear in mind that some of us are in situations where what the
latest release of Ubunutu is not really relevant.
Our organisation uses CentOS 6, which is not EOL until the end of
2020. In CentOS 6, the stock version of python is python 2.6; we go
through special measures (EPEL) to get that up to python 2.7. If we
wanted to make the move to Python 3, we'd be talking about Python 3.4,
again through EPEL.
We have an infrastructure team responsible for provisioning servers,
and it is on their schedule that OS upgrades occur - it is not easy
for us as developers to argue that this team should spend significant
resource to upgrade to a later OS version or to roll custom python
RPMs.
Updating all of our codebase to Python 3 is going to be a pain for us,
it is hard to argue a business need with "Everything stays exactly the
same but is slightly more secure and easier to maintain".
Realistically, when we move to Python 3, it will be because the
supported Django LTS requires it. If we also have to jump through lots
of hoops to get the very latest Python 3 release, it won't make it
easier to argue, it will mean we are more likely to postpone it and
keep using old django versions, particularly on internal intranet
sites.
If there is a way that Python 3.4 support can be maintained without
significant detriment or penalty, this would be greatly appreciated by
those of us running more conservative enterprise distributions.
Cheers
Tom

[Tim Graham]

I don't know if matters to anyone, but I guess as long as we support Python
3.4 we can't do the type hinting project (PEP 484) since that's new in 3.5?

Post by Tim Graham
Tom, I'm not following how Python 3.4 support in Django 2.0 will benefit
you if you want to stick to LTS versions of Django? I think either you or I
Django 1.11 is the next LTS. It's supported until April 2020 and supports
Python 3.4. The next LTS, Django 2.2 is due in April 2019, after the Python
3.4 end of life in March 2019 -- so I don't think we can justify supporting
Python 3.4 in that LTS unless we decide to base our supported Python policy
on CentOS rather than Python's own support lifecycle. Florian and Daniele
are proposing supporting Python 3.4 for Django 2.0 and/or 2.1. Those
versions have security support ending in April 2019 and December 2019,
respectively. If you want to use Python 3.4 and maximize the time you can
receive Django security updates, stick with 1.11 LTS (April 2020).
https://www.djangoproject.com/download/#supported-versions
https://docs.python.org/devguide/#status-of-python-branches

Post by 'Tom Evans' via Django developers (Contributions to Django itself)

Post by Asif Saifuddin
Hi,
django 2.0 will be released in december 2017 and ubuntu 18.04 will be
released in april 2018 which will default atleast 3.6, so I think this
should also be taken as consideration while deciding.

I know supporting endless versions of python is not desirable, but
please bear in mind that some of us are in situations where what the
latest release of Ubunutu is not really relevant.
Our organisation uses CentOS 6, which is not EOL until the end of
2020. In CentOS 6, the stock version of python is python 2.6; we go
through special measures (EPEL) to get that up to python 2.7. If we
wanted to make the move to Python 3, we'd be talking about Python 3.4,
again through EPEL.
We have an infrastructure team responsible for provisioning servers,
and it is on their schedule that OS upgrades occur - it is not easy
for us as developers to argue that this team should spend significant
resource to upgrade to a later OS version or to roll custom python
RPMs.
Updating all of our codebase to Python 3 is going to be a pain for us,
it is hard to argue a business need with "Everything stays exactly the
same but is slightly more secure and easier to maintain".
Realistically, when we move to Python 3, it will be because the
supported Django LTS requires it. If we also have to jump through lots
of hoops to get the very latest Python 3 release, it won't make it
easier to argue, it will mean we are more likely to postpone it and
keep using old django versions, particularly on internal intranet
sites.
If there is a way that Python 3.4 support can be maintained without
significant detriment or penalty, this would be greatly appreciated by
those of us running more conservative enterprise distributions.
Cheers
Tom

[James Bennett]

Post by Tim Graham
I don't know if matters to anyone, but I guess as long as we support
Python 3.4 we can't do the type hinting project (PEP 484) since that's new
The typing module also exists standalone on PyPI and thus is pip
installable for Python 3 < 3.5.

[Daniel Moisset]

Type hinting can be done in python 3.x by depending on the typing module
(or inlining it). Type hinting for instance/class attributes will have a
much nicer syntax in python 3.6 only (PEP 526)

Best,
D.

Post by Tim Graham
I don't know if matters to anyone, but I guess as long as we support
Python 3.4 we can't do the type hinting project (PEP 484) since that's new
in 3.5?

Post by Tim Graham
Tom, I'm not following how Python 3.4 support in Django 2.0 will benefit
you if you want to stick to LTS versions of Django? I think either you or I
Django 1.11 is the next LTS. It's supported until April 2020 and supports
Python 3.4. The next LTS, Django 2.2 is due in April 2019, after the Python
3.4 end of life in March 2019 -- so I don't think we can justify supporting
Python 3.4 in that LTS unless we decide to base our supported Python policy
on CentOS rather than Python's own support lifecycle. Florian and Daniele
are proposing supporting Python 3.4 for Django 2.0 and/or 2.1. Those
versions have security support ending in April 2019 and December 2019,
respectively. If you want to use Python 3.4 and maximize the time you can
receive Django security updates, stick with 1.11 LTS (April 2020).
https://www.djangoproject.com/download/#supported-versions
https://docs.python.org/devguide/#status-of-python-branches

Post by 'Tom Evans' via Django developers (Contributions to Django itself)

Post by Asif Saifuddin
Hi,
django 2.0 will be released in december 2017 and ubuntu 18.04 will be
released in april 2018 which will default atleast 3.6, so I think this
should also be taken as consideration while deciding.

I know supporting endless versions of python is not desirable, but
please bear in mind that some of us are in situations where what the
latest release of Ubunutu is not really relevant.
Our organisation uses CentOS 6, which is not EOL until the end of
2020. In CentOS 6, the stock version of python is python 2.6; we go
through special measures (EPEL) to get that up to python 2.7. If we
wanted to make the move to Python 3, we'd be talking about Python 3.4,
again through EPEL.
We have an infrastructure team responsible for provisioning servers,
and it is on their schedule that OS upgrades occur - it is not easy
for us as developers to argue that this team should spend significant
resource to upgrade to a later OS version or to roll custom python
RPMs.
Updating all of our codebase to Python 3 is going to be a pain for us,
it is hard to argue a business need with "Everything stays exactly the
same but is slightly more secure and easier to maintain".
Realistically, when we move to Python 3, it will be because the
supported Django LTS requires it. If we also have to jump through lots
of hoops to get the very latest Python 3 release, it won't make it
easier to argue, it will mean we are more likely to postpone it and
keep using old django versions, particularly on internal intranet
sites.
If there is a way that Python 3.4 support can be maintained without
significant detriment or penalty, this would be greatly appreciated by
those of us running more conservative enterprise distributions.
Cheers
Tom

--

You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/
msgid/django-developers/680d3d55-a9d4-46d9-a587-
c49649f24cbf%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/680d3d55-a9d4-46d9-a587-c49649f24cbf%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

--
Daniel F. Moisset - UK Country Manager
www.machinalis.com
Skype: @dmoisset

[Florian Apolloner]

Post by Tim Graham
I don't know if matters to anyone, but I guess as long as we support
Python 3.4 we can't do the type hinting project (PEP 484) since that's new
in 3.5?

I do not think this matters, first off there is no commitment from our side
on type hinting or anything. We do not have any DEP or something related
and didn't even discuss if we actually want type hinting. Personally I am
kinda against it anyways, since it clutters the code for not much gain. So
if we were to do it, I would prefer stub files anyways, in which case we
won't depend on any python version as far as I understood that.

[Claude Paroz]

I would like to voice my support for Florian's arguments. It's not only
RedHat, Debian is also concerned. The current Jessie stable version which
will be supported probably until mid-2018 is Python 3.4, and the upcoming
stable version will most probably be Python 3.5. So a strong -1 for
dropping 3.5 for Django 2.0. For Python 3.4, we might bring the issue to
the technical board.
Dropping Python 2 will already be a strong progress and might allow nice
improvements for Django.

Claude

Post by Florian Apolloner
Imo we should not drop Python versions overeagerly. After all I do not
wanna compile our own python for djangoproject.com :D Given that Redhat
is on Python 3.4 for the foreseeable future, I'd actually even like to see
3.4 still supported in Django 2.0 unless there is a good reason to drop it.
Fwiw, Ubuntu Trusty which is LTS and still supported also is on Python 3.4.
So unless there are compelling arguments to drop 3.4, lets keep it as long
as it is not too much work.
Either way, I am completely against dropping Python 3.5 now -- lets make
the Django 2.0 migration not more painful than it has to be (ie I do not
want to force people to upgrade existing supported systems just to get the
latest python and therefor Django).
Cheers,
Florian

[Aymeric Augustin]

Dropping Python 2 will already be a strong progress and might allow nice improvements for Django.

+1

The Python 3 transition will materialize brutally for many developers when they can’t upgrade Django anymore without upgrading Python as well.

I’m in favor of not making it more difficult to upgrade to Python 3 by not supporting versions available on Debian or Ubuntu stable.

(This isn’t an argument for supporting a particular version; I didn’t check the timeline precisely; it's a general inclination.)
--
Aymeric.

[Claude Paroz]

Any idea why my message in this thread was deleted?

Claude

[Tim Graham]

There may be a bug in Google Groups -- I've seen my own messages deleted
like that.

Post by Claude Paroz
Any idea why my message in this thread was deleted?
Claude

[Karen Tracey]

Post by Claude Paroz
Any idea why my message in this thread was deleted?

No idea. It was held in moderation as "possible spam" for reason only
Google Groups knows. When GG does this, it does not send moderators a note
about it until 3 or 4 days later. This one I happened to see when I went to
moderate a post from a first-time poster, and I sent both through. It came
through in email. No idea why in the group it shows up as "deleted". Maybe
it will re-appear in the group eventually...

Karen

[Florian Apolloner]

After thinking a bit more: Are there any concrete reasons to drop 3.4/3.5
aside from new features? Sure, security is an issue, but looking at the
issues with cookie parsing we would have been better off by immediately
fixing ourself instead of waiting for python (same goes for XML). So in the
end, while I usually advocate for security and up2date systems, I do not
think we gain much by dropping python 3.4 and/or 3.5.

I cannot speak for everyone else, but I do have the feeling that Django
will get somewhat annoying to deploy for me (Don't get me wrong, I am
getting paid to do that, but other people are not in such a lucky situation
and I'd still like to see Django grow in enterprise environments). We are
on RedHat 7, which I'll certainly stay on for a while. I can probably fetch
newer python versions from IUS, but then I'll have to recompile mod_wsgi
etc
 Given that RedHat does not package Django at all, I am running from
the upstream releases, which is perfectly fine for me -- but it would be
great if I can use somewhat newer Django versions too.

In the end (in my experience), people are using Django everywhere and part
of the usage also comes from the fact that it's not that hard to deploy for
sysadmins since python is available anywhere; compiling a new Python +
infrastructure around it is something else again and requires a lot of
change requests in some companies.

No matter how we decide, I'd like to see python 3.4 supported on Django 2.0
to ensure that people that wanna upgrade can at least try the first
py3-only version without having to upgrade their systems (Ubuntu Trusty is
still on 3.4 and still supported). And then maybe try to get some feedback
from some companies and the versions of python they are using on Django 2.0.

Cheers,
Florian

Post by Tim Graham
When I drafted the 1.11 release notes in May, I wrote, "The next major
release, Django 2.0, will only support Python 3.5+."
Our Python version support policy is "Typically, we will support a Python
version up to and including the first Django LTS release whose security
support ends after security support for that version of Python ends."
Python 3.5's EOL is September 2020 which I think is sufficiently close to
Django 1.11's EOL of April 2020 that we could say Django 2.0 is Python
3.6+. The alternative is not to drop Python 3.5 compatibility until Django
2.2 LTS which is supported until April 2022. I don't see much advantage to
that. Any objections?
p.s. There is already a ticket suggesting to take advantage of a Python
https://code.djangoproject.com/ticket/27635* - *django.utils.crypto
should use secrets on Python 3.6+

[Florian Apolloner]

"EDIT://" Oh, and while it is true that it is a bit more work for us to
support multiple python versions, I've never seen it that bad. Installing
more CI runners which have the matching python versions does not hurt that
much either. Actually it might nowadays even be easier on CentOS than on
Ubuntu given that the deadsnakes repo is somewhat dead nowadays if I
understood that correctly.

[Daniele Procida]

Post by Florian Apolloner
In the end (in my experience), people are using Django everywhere and part
of the usage also comes from the fact that it's not that hard to deploy for
sysadmins since python is available anywhere; compiling a new Python +
infrastructure around it is something else again and requires a lot of
change requests in some companies.

In practical terms it makes a big difference. Remember <https://groups.google.com/forum/#!topic/django-developers/qCjfOu-FPxQ/discussion>, that prompted a change of LTS policy?

*Anything* that makes the transition easier is to be welcomed, and that doesn't just mean technically easier, it also means easier to think about and to talk about to project managers and clients and web project owners.

Reassurance in time of change counts for a great deal. When someone gets to spend a day or two basking in the glory of a top item on Hacker News because he wrote a "Don't go to Python 3" article, there is clearly some reassuring to be done.

If the technical cost of supporting 3.4 in Django 2.0 is not too high, I feel it would be valuable to have it.

The actual technical justification for keeping it may be weak, but barriers to adoption are not always technical ones anyway, and my preference would be to keep them as low as possible.

Daniele

[Aymeric Augustin]

Hello,

I agreed with Florian and Daniele. Python 3.4 will be supported until March 2019, giving it over 1 year of overlap with Django 2.0, including the entire mainstream support period.

I don’t expect supporting Python 3.4 to be a burden or dropping it to allow large gains. The language-level differences with Python 3.5 and 3.6 are minimal, unless I missed things that matter for Django, that is, allow us to remove problematic code.

<dinosaur>It’s a different story from Python 2.4 vs. 2.5 vs. 2.6: back then `except Exception as exc` would break older Pythons until someone reported it and we didn’t have CI. Good times.</dinosaur>

Perhaps we could update the support policy to say: Django X.Y will support Python versions that are under security support until the end of mainstream support for Django X.Y. The difference with the current policy is “mainstream support” instead of “extended support”.

Without changing the official policy, I think it would be nice to be more lenient with supported Python 3.x versions in the version of Django than drops Python 2. This isn’t a technical argument, it’s a marketing / developer relations argument. That doesn’t make it invalid :-)

And even if we keep support for Python 3.4 we’ll still be make our lives incredibly easier by dropping support for Python 2.

Best regards,
--
Aymeric.

[Tim Graham]

So you all want to do a one time exception to our guidance of of "Typically
we will support a Python version up to and including the first Django LTS
release whose security support ends after security support for that version
of Python ends." and support Python 3.4 for how long? Or revise the
guidance?

Post by Daniele Procida

Post by Florian Apolloner
In the end (in my experience), people are using Django everywhere and

part

Post by Florian Apolloner
of the usage also comes from the fact that it's not that hard to deploy

for

Post by Florian Apolloner
sysadmins since python is available anywhere; compiling a new Python +
infrastructure around it is something else again and requires a lot of
change requests in some companies.

In practical terms it makes a big difference. Remember <
https://groups.google.com/forum/#!topic/django-developers/qCjfOu-FPxQ/discussion>,
that prompted a change of LTS policy?
*Anything* that makes the transition easier is to be welcomed, and that
doesn't just mean technically easier, it also means easier to think about
and to talk about to project managers and clients and web project owners.
Reassurance in time of change counts for a great deal. When someone gets
to spend a day or two basking in the glory of a top item on Hacker News
because he wrote a "Don't go to Python 3" article, there is clearly some
reassuring to be done.
If the technical cost of supporting 3.4 in Django 2.0 is not too high, I
feel it would be valuable to have it.
The actual technical justification for keeping it may be weak, but
barriers to adoption are not always technical ones anyway, and my
preference would be to keep them as low as possible.
Daniele

[Florian Apolloner]

Not sure on how we'd put that into text, but something along the lines of
"we will support 3.4+ as long as feasible for us to do so" -- though I do
understand that this is like the same as saying: "We'll just support what
we want, how long we want" :D

Post by Tim Graham
So you all want to do a one time exception to our guidance of of
"Typically we will support a Python version up to and including the first
Django LTS release whose security support ends after security support for
that version of Python ends." and support Python 3.4 for how long? Or
revise the guidance?

Post by Daniele Procida

Post by Florian Apolloner
In the end (in my experience), people are using Django everywhere and

part

Post by Florian Apolloner
of the usage also comes from the fact that it's not that hard to deploy

for

Post by Florian Apolloner
sysadmins since python is available anywhere; compiling a new Python +
infrastructure around it is something else again and requires a lot of
change requests in some companies.

In practical terms it makes a big difference. Remember <
https://groups.google.com/forum/#!topic/django-developers/qCjfOu-FPxQ/discussion>,
that prompted a change of LTS policy?
*Anything* that makes the transition easier is to be welcomed, and that
doesn't just mean technically easier, it also means easier to think about
and to talk about to project managers and clients and web project owners.
Reassurance in time of change counts for a great deal. When someone gets
to spend a day or two basking in the glory of a top item on Hacker News
because he wrote a "Don't go to Python 3" article, there is clearly some
reassuring to be done.
If the technical cost of supporting 3.4 in Django 2.0 is not too high, I
feel it would be valuable to have it.
The actual technical justification for keeping it may be weak, but
barriers to adoption are not always technical ones anyway, and my
preference would be to keep them as low as possible.
Daniele

[Daniele Procida]

Post by Florian Apolloner
Not sure on how we'd put that into text, but something along the lines of
"we will support 3.4+ as long as feasible for us to do so" -- though I do
understand that this is like the same as saying: "We'll just support what
we want, how long we want" :D

For the purposes of being reassuring, it needs to be concrete, otherwise we're just moving people's doubt and uncertainty around!


It seems reasonable that Django 2.0 should continue to support Python 3.4, and that Django 2.1 should not. That provides a decent ledge of overlap for those climbing up these tricky upgrade paths to rest on and catch their breath.

Daniele

[Tim Graham]

Daniele, here's my try at being more concrete than "It seems reasonable"
and "decent ledge of overlap". Let me know if you meant something different!

"Django 2.0 will be the last version of Django to support Python 3.4. This
allows those running older operating systems with Python 3.4 (such as
Ubuntu 14.04 and CentOS 6) to use the latest version of Django for an
additional eight months. If you don't intend to upgrade to a system with
Python 3.5 or later by the end of security updates for Django 2.0 in April
2019, stick with Django 1.11 LTS which is supported until April 2020."

I'd rather not allow Python 3.4 users to strand themselves on Django 2.0
when sticking with 1.11 would provide longer security support (lesson
learned from Python 2.6 users stranded on Django 1.6), but hopefully
documenting this danger will help prevent that this time around.

Post by Daniele Procida

Post by Florian Apolloner
Not sure on how we'd put that into text, but something along the lines of
"we will support 3.4+ as long as feasible for us to do so" -- though I do
understand that this is like the same as saying: "We'll just support what
we want, how long we want" :D

For the purposes of being reassuring, it needs to be concrete, otherwise
we're just moving people's doubt and uncertainty around!
It seems reasonable that Django 2.0 should continue to support Python 3.4,
and that Django 2.1 should not. That provides a decent ledge of overlap for
those climbing up these tricky upgrade paths to rest on and catch their
breath.
Daniele

[roboslone]

I do not think this matters, first off there is no commitment from our side on type hinting or anything. We do not have any DEP or something related and didn't even discuss if we actually want type hinting. Personally I am kinda against it anyways, since it clutters the code for not much gain. So if we were to do it, I would prefer stub files anyways, in which case we won't depend on any python version as far as I understood that.

As Django user, I have to say type hinting would help a lot to understand how things work in Django without looking at docs. It could save a lot of time for beginners, too. Also I have to mention, that PyCharm (which is the most popular IDE for Python, I believe) has support for type hinting and could help you avoid many problems before even firing up a server.

In my opinion not adding type hints in Django 2.0 would be a mistake.

"Django 2.0 will be the last version of Django to support Python 3.4. This allows those running older operating systems with Python 3.4 (such as Ubuntu 14.04 and CentOS 6) to use the latest version of Django for an additional eight months. If you don't intend to upgrade to a system with Python 3.5 or later by the end of security updates for Django 2.0 in April 2019, stick with Django 1.11 LTS which is supported until April 2020."

As to Python 3.4 support, Django 1.11 will be LTS and most projects written with Django <=1.10 will probably stay on LTS version. Using Django 2.0 in existing project would require rewriting some bits anyway (correct me if I'm wrong), so there's really not much point in sticking to Python 3.4/3.5 in my opinion. If you're rewriting your code to use new version of Django, you could as well use new version of Python. Isn't it the whole point of major release?

Sticking to 3.6 would allow using format strings, and that would greatly increase readability (looking at %-strings here). To be honest, using str.format on string with many variables can hurt readability almost as much as % does. Also, variable annotation only appeared in 3.6, so supporting Python 3.5 an older would mean that variable annotation is only possible using comments (which is not necessarily a bad thing, tough it has some downsides as pointed out in PEP-526).

I have to add, that nowadays deploying python applications with desired version of Python is fairly easy. One could use relocatable virtualenvs, Docker containers and so on. So even if you're on an outdated distro (or something like RHEL, that wouldn't get new python version in ages, probably) and your OS is stuck with older version of Python, your application doesn't have to be.

Since there're a lot of Django users out there who aren't subscribed to this mailing list, I suggest to sum up this discussion in a blog post and let users vote. I believe a big "Help decide Django 2.0 fate" button on djangoproject.com would attract much more attention to the issue. Maybe most of Django users are ready to migrate to Python 3.6 when they switch to Django 2.0 (probably not, but who knows) and developers could start enjoying new Python features a year or two earlier.

P.S. Please treat everything above as a personal opinion, I'm probably wrong about some things. And sorry for a bad English, it's not my native language.

Daniele, here's my try at being more concrete than "It seems reasonable" and "decent ledge of overlap". Let me know if you meant something different!
"Django 2.0 will be the last version of Django to support Python 3.4. This allows those running older operating systems with Python 3.4 (such as Ubuntu 14.04 and CentOS 6) to use the latest version of Django for an additional eight months. If you don't intend to upgrade to a system with Python 3.5 or later by the end of security updates for Django 2.0 in April 2019, stick with Django 1.11 LTS which is supported until April 2020."
I'd rather not allow Python 3.4 users to strand themselves on Django 2.0 when sticking with 1.11 would provide longer security support (lesson learned from Python 2.6 users stranded on Django 1.6), but hopefully documenting this danger will help prevent that this time around.

Post by Florian Apolloner
Not sure on how we'd put that into text, but something along the lines of
"we will support 3.4+ as long as feasible for us to do so" -- though I do
understand that this is like the same as saying: "We'll just support what
we want, how long we want" :D

For the purposes of being reassuring, it needs to be concrete, otherwise we're just moving people's doubt and uncertainty around!
It seems reasonable that Django 2.0 should continue to support Python 3.4, and that Django 2.1 should not. That provides a decent ledge of overlap for those climbing up these tricky upgrade paths to rest on and catch their breath.
Daniele
--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
Visit this group at https://groups.google.com/group/django-developers <https://groups.google.com/group/django-developers>.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/68cfdafc-730c-42bb-a772-4f17193645f5%40googlegroups.com <https://groups.google.com/d/msgid/django-developers/68cfdafc-730c-42bb-a772-4f17193645f5%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

[Josh Smeaton]

I guess I don't really see how we'd be helping users in any meaningful way
by supporting python 3.4 with Django 2.0. Django 2.0's defining change is
dropping Python 2. We have no idea what else will land in 2.0.

If we're trying to consider Enterprise users on "older" Distros:

- 1.11 will be LTS and will be supported for **longer** than Django 2.0
will be.
- 1.11 supports 2.7 through to 3.6.
- The next LTS, which is likely the next version of Django for these Users,
will support 3.6+

If we're wanting users to upgrade their code bases to run on Python 3, then
they certainly won't be doing it on Django 2.0. If they plan to move to
Python 3 at all, it'll be on 1.11 or 2.2.
And if they want to be running on the latest and greatest Django, then why
shouldn't that extend to adding an RPM repo or RedHat-SCL and installing
the latest Python?

I admit to a lack of knowledge on how to install new versions of Python on
Ubuntu-likes. But https://ius.io/ is a great Redhat/Centos repo for
installing newer Python versions.

[Asif Saifuddin]

Hi Josh,

I do agree and support your idea's. How about pointing/recommend pyenv for
deployment in the doc?

Thanks,
Asif

Post by Josh Smeaton
I guess I don't really see how we'd be helping users in any meaningful way
by supporting python 3.4 with Django 2.0. Django 2.0's defining change is
dropping Python 2. We have no idea what else will land in 2.0.
- 1.11 will be LTS and will be supported for **longer** than Django 2.0
will be.
- 1.11 supports 2.7 through to 3.6.
- The next LTS, which is likely the next version of Django for these
Users, will support 3.6+
If we're wanting users to upgrade their code bases to run on Python 3,
then they certainly won't be doing it on Django 2.0. If they plan to move
to Python 3 at all, it'll be on 1.11 or 2.2.
And if they want to be running on the latest and greatest Django, then why
shouldn't that extend to adding an RPM repo or RedHat-SCL and installing
the latest Python?
I admit to a lack of knowledge on how to install new versions of Python on
Ubuntu-likes. But https://ius.io/ is a great Redhat/Centos repo for
installing newer Python versions.

[Josh Smeaton]

I don't think pyenv is really relevant to this discussion and not something
we really need to promote. pyenv deals with making a particular installed
python *available*, it doesn't handle the installation of that python.

Post by Asif Saifuddin
Hi Josh,
I do agree and support your idea's. How about pointing/recommend pyenv for
deployment in the doc?
Thanks,
Asif

Post by Josh Smeaton
I guess I don't really see how we'd be helping users in any meaningful
way by supporting python 3.4 with Django 2.0. Django 2.0's defining change
is dropping Python 2. We have no idea what else will land in 2.0.
- 1.11 will be LTS and will be supported for **longer** than Django 2.0
will be.
- 1.11 supports 2.7 through to 3.6.
- The next LTS, which is likely the next version of Django for these
Users, will support 3.6+
If we're wanting users to upgrade their code bases to run on Python 3,
then they certainly won't be doing it on Django 2.0. If they plan to move
to Python 3 at all, it'll be on 1.11 or 2.2.
And if they want to be running on the latest and greatest Django, then
why shouldn't that extend to adding an RPM repo or RedHat-SCL and
installing the latest Python?
I admit to a lack of knowledge on how to install new versions of Python
on Ubuntu-likes. But https://ius.io/ is a great Redhat/Centos repo for
installing newer Python versions.

[Josh Smeaton]

Apparently I'm dumb and didn't read enough. pyenv *does* take care of
installation too. I'm not familiar enough with it (obviously..) to know
whether or not we should be encouraging its use.

Post by Josh Smeaton
I don't think pyenv is really relevant to this discussion and not
something we really need to promote. pyenv deals with making a particular
installed python *available*, it doesn't handle the installation of that
python.

Post by Asif Saifuddin
Hi Josh,
I do agree and support your idea's. How about pointing/recommend pyenv
for deployment in the doc?
Thanks,
Asif

Post by Josh Smeaton
I guess I don't really see how we'd be helping users in any meaningful
way by supporting python 3.4 with Django 2.0. Django 2.0's defining change
is dropping Python 2. We have no idea what else will land in 2.0.
- 1.11 will be LTS and will be supported for **longer** than Django 2.0
will be.
- 1.11 supports 2.7 through to 3.6.
- The next LTS, which is likely the next version of Django for these
Users, will support 3.6+
If we're wanting users to upgrade their code bases to run on Python 3,
then they certainly won't be doing it on Django 2.0. If they plan to move
to Python 3 at all, it'll be on 1.11 or 2.2.
And if they want to be running on the latest and greatest Django, then
why shouldn't that extend to adding an RPM repo or RedHat-SCL and
installing the latest Python?
I admit to a lack of knowledge on how to install new versions of Python
on Ubuntu-likes. But https://ius.io/ is a great Redhat/Centos repo for
installing newer Python versions.

[Asif Saifuddin]

Hi Josh,

How about keeping 3.5 support in 2.0.0? say the users of ubuntu 16.04 using
systems python3.5 and update to 2.0 or started a new project with dj2.0.0
in ubuntu 16.04.

About pyenv, it take care of installing and using different versions of
python in a system without hampering the system python. There could be some
pointer about possible alternatives IMHO.

I use pyenv regularly and it makes like of a python developer really great.

Thanks

Post by Josh Smeaton
Apparently I'm dumb and didn't read enough. pyenv *does* take care of
installation too. I'm not familiar enough with it (obviously..) to know
whether or not we should be encouraging its use.

Post by Josh Smeaton
I don't think pyenv is really relevant to this discussion and not
something we really need to promote. pyenv deals with making a particular
installed python *available*, it doesn't handle the installation of that
python.

Post by Asif Saifuddin
Hi Josh,
I do agree and support your idea's. How about pointing/recommend pyenv
for deployment in the doc?
Thanks,
Asif

Post by Josh Smeaton
I guess I don't really see how we'd be helping users in any meaningful
way by supporting python 3.4 with Django 2.0. Django 2.0's defining change
is dropping Python 2. We have no idea what else will land in 2.0.
- 1.11 will be LTS and will be supported for **longer** than Django 2.0
will be.
- 1.11 supports 2.7 through to 3.6.
- The next LTS, which is likely the next version of Django for these
Users, will support 3.6+
If we're wanting users to upgrade their code bases to run on Python 3,
then they certainly won't be doing it on Django 2.0. If they plan to move
to Python 3 at all, it'll be on 1.11 or 2.2.
And if they want to be running on the latest and greatest Django, then
why shouldn't that extend to adding an RPM repo or RedHat-SCL and
installing the latest Python?
I admit to a lack of knowledge on how to install new versions of Python
on Ubuntu-likes. But https://ius.io/ is a great Redhat/Centos repo for
installing newer Python versions.

[Florian Apolloner]

Hi Josh,

Post by Josh Smeaton
I guess I don't really see how we'd be helping users in any meaningful way
by supporting python 3.4 with Django 2.0. Django 2.0's defining change is
dropping Python 2. We have no idea what else will land in 2.0.

Django evolves, there are new things in every release and if possible I'd
rather have more people testing new short-term-support releases.

Post by Josh Smeaton
If we're wanting users to upgrade their code bases to run on Python 3,
then they certainly won't be doing it on Django 2.0.

Maybe, maybe not, I just don't want to have the one release that drops
Python 2.0 also be the one release that moves the Python version support to
an "island"-solution which just supports py3.6 (or maybe 3.7 by that time).
Even if we leave RHEL out of it, I'd very much like people on their dev
machines with a still supported ubuntu LTS (ie 16.04) to be able to try
Django 2.0, which is certainly an argument against dropping 3.5 at least.
You are right that 3.4 might be far stretching, but again, if it doesn't
cost us much, but gives us a wide range of supported systems, why not?
Given that 1.11 supports 3.4 anyways, there is also no extra burden on the
CI machines (maintenance wise) aside from a bigger build matrix.

I admit to a lack of knowledge on how to install new versions of Python on

Post by Josh Smeaton
Ubuntu-likes. But https://ius.io/ is a great Redhat/Centos repo for
installing newer Python versions.

Yes ius/scl are relatively great, but the miss glue code -- ie you get a
new Python, but you still need to recompile mod_wsgi for instance
 That
said, with the deadsnakes repo dead, I think new CI server for django would
probably be using CentOS since that is an easy way to get access to py 2.7
& 3.4-3.6.

Cheers,
Florian

[Florian Apolloner]

Hi,

Post by roboslone
As Django user, I have to say type hinting would help a lot to understand
how things work in Django without looking at docs. It could save a lot of
time for beginners, too.

I've been working with "type hinting" in CPP and Java IDEs for years and
can't say that they saved me from looking at the Docs. Quite often they
actually made me write worse code since I was missing tips from the
documentation. I nowadays quite often just work with in-file completion,
nothing fancy.

Also I have to mention, that PyCharm (which is the most popular IDE for

Post by roboslone
Python, I believe) has support for type hinting and could help you avoid
many problems before even firing up a server.

Cannot speak for PyCharm, I try it once a year or so and am so annoyed by
it that I drop it before the end of the day usually.

Post by roboslone
In my opinion not adding type hints in Django 2.0 would be a mistake.

Maybe, but that will require someone convinced to step up. All I hear so
far is that type hinting would be nice to have, but I do not see any
concrete proposals anywhere. And even if we allow python 3.4, we can
support type hinting via stub files.

Post by roboslone
Using Django 2.0 in existing project would require rewriting some bits
anyway (correct me if I'm wrong)

Not more rewriting than lets say 1.10 -> 1.11, the increase in the version
number is because we are dropping python 2, not because we are going to
break backwards compat like rails 3 -> 4 (excuse me if I got the version
numbers wrong)

Post by roboslone
If you're rewriting your code to use new version of Django, you could as
well use new version of Python.

I'd be honestly surprised by that, updating Django is way easier than
installing a new Python version.

Post by roboslone
Sticking to 3.6 would allow using format strings, and that would greatly
increase readability (looking at %-strings here).

Knowing what certain members of the core team think about those f-strings,
I think there will be first a big discussion if we will allow them at all
in Django's codebase. Then there are further things to consider like
gettext support etc


Post by roboslone
I have to add, that nowadays deploying python applications with desired
version of Python is fairly easy. One could use relocatable virtualenvs,
Docker containers and so on.

No it is not that easy, even if you make a venv relocatable it is not ment
to be copied to a system not supporting that python version. And sadly
containers are not always an option.

Post by roboslone
So even if you're on an outdated distro (or something like RHEL, that
wouldn't get new python version in ages, probably) and your OS is stuck
with older version of Python, your application doesn't have to be.

I guess that is where we have to disagree.

and developers could start enjoying new Python features a year or two

Post by roboslone
earlier.

Noone is stopping you to use new Python features in your own code, but
there is currently no convincing reason to force Django onto a new Python
version imo.

Cheers,
Florian

[Cheng Chi]

+1 on type hinting. PyCharm always gives me 20+ options when I want to jump
to the definition of modelInstance.save() method (or any other method with
a common name like save), which makes me really miss static type
languages... As the framework for perfectionists with deadlines, I think
type hinting (with IDE) does help a lot on productivity for many developers
who are not experts on Django core.

Since django core is considerably mature and no major new feature is on the
horizon currently, I'd like to see more python language features adopted as
django evolving.

Post by Florian Apolloner
I do not think this matters, first off there is no commitment from our
side on type hinting or anything. We do not have any DEP or something
related and didn't even discuss if we actually want type hinting.
Personally I am kinda against it anyways, since it clutters the code for
not much gain. So if we were to do it, I would prefer stub files anyways,
in which case we won't depend on any python version as far as I understood
that.
As Django user, I have to say type hinting would help a lot to understand
how things work in Django without looking at docs. It could save a lot of
time for beginners, too. Also I have to mention, that PyCharm (which is the
most popular IDE for Python, I believe) has support for type hinting and
could help you avoid many problems before even firing up a server.
In my opinion not adding type hints in Django 2.0 would be a mistake.
"Django 2.0 will be the last version of Django to support Python 3.4. This
allows those running older operating systems with Python 3.4 (such as
Ubuntu 14.04 and CentOS 6) to use the latest version of Django for an
additional eight months. If you don't intend to upgrade to a system with
Python 3.5 or later by the end of security updates for Django 2.0 in April
2019, stick with Django 1.11 LTS which is supported until April 2020."
As to Python 3.4 support, Django 1.11 will be LTS and most projects
written with Django <=1.10 will probably stay on LTS version. Using Django
2.0 in existing project would require rewriting some bits anyway (correct
me if I'm wrong), so there's really not much point in sticking to Python
3.4/3.5 in my opinion. If you're rewriting your code to use new version of
Django, you could as well use new version of Python. Isn't it the whole
point of major release?
Sticking to 3.6 would allow using format strings, and that would greatly
increase readability (looking at %-strings here). To be honest, using
str.format on string with many variables can hurt readability almost as
much as % does. Also, variable annotation only appeared in 3.6, so
supporting Python 3.5 an older would mean that variable annotation is only
possible using comments (which is not necessarily a bad thing, tough it has
some downsides as pointed out in PEP-526).
I have to add, that nowadays deploying python applications with desired
version of Python is fairly easy. One could use relocatable virtualenvs,
Docker containers and so on. So even if you're on an outdated distro (or
something like RHEL, that wouldn't get new python version in ages,
probably) and your OS is stuck with older version of Python, your
application doesn't have to be.
Since there're a lot of Django users out there who aren't subscribed to
this mailing list, I suggest to sum up this discussion in a blog post and
let users vote. I believe a big "Help decide Django 2.0 fate" button on
djangoproject.com would attract much more attention to the issue. Maybe
most of Django users are ready to migrate to Python 3.6 when they switch to
Django 2.0 (probably not, but who knows) and developers could start
enjoying new Python features a year or two earlier.
P.S. Please treat everything above as a personal opinion, I'm probably
wrong about some things. And sorry for a bad English, it's not my native
language.
Daniele, here's my try at being more concrete than "It seems reasonable"
and "decent ledge of overlap". Let me know if you meant something different!
"Django 2.0 will be the last version of Django to support Python 3.4. This
allows those running older operating systems with Python 3.4 (such as
Ubuntu 14.04 and CentOS 6) to use the latest version of Django for an
additional eight months. If you don't intend to upgrade to a system with
Python 3.5 or later by the end of security updates for Django 2.0 in April
2019, stick with Django 1.11 LTS which is supported until April 2020."
I'd rather not allow Python 3.4 users to strand themselves on Django 2.0
when sticking with 1.11 would provide longer security support (lesson
learned from Python 2.6 users stranded on Django 1.6), but hopefully
documenting this danger will help prevent that this time around.

Post by Daniele Procida

Post by Florian Apolloner
Not sure on how we'd put that into text, but something along the lines

of

Post by Florian Apolloner
"we will support 3.4+ as long as feasible for us to do so" -- though I

do

Post by Florian Apolloner
understand that this is like the same as saying: "We'll just support

what

Post by Florian Apolloner
we want, how long we want" :D

For the purposes of being reassuring, it needs to be concrete, otherwise
we're just moving people's doubt and uncertainty around!
It seems reasonable that Django 2.0 should continue to support Python
3.4, and that Django 2.1 should not. That provides a decent ledge of
overlap for those climbing up these tricky upgrade paths to rest on and
catch their breath.
Daniele

--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an
<javascript:>.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/68cfdafc-730c-42bb-a772-4f17193645f5%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/68cfdafc-730c-42bb-a772-4f17193645f5%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

[Tim Graham]

I propose to tentatively target Python 3.5+ for Django 2.0 but not to
remove the current workarounds for Python 3.4 at this time. Shortly before
the alpha for Django 2.0, an interested person can look into how much work
is required to fix any test failures on Python 3.4 and we'll make a
decision then.

Post by Cheng Chi
+1 on type hinting. PyCharm always gives me 20+ options when I want to
jump to the definition of modelInstance.save() method (or any other method
with a common name like save), which makes me really miss static type
languages... As the framework for perfectionists with deadlines, I think
type hinting (with IDE) does help a lot on productivity for many developers
who are not experts on Django core.
Since django core is considerably mature and no major new feature is on
the horizon currently, I'd like to see more python language features
adopted as django evolving.

Post by Florian Apolloner
I do not think this matters, first off there is no commitment from our
side on type hinting or anything. We do not have any DEP or something
related and didn't even discuss if we actually want type hinting.
Personally I am kinda against it anyways, since it clutters the code for
not much gain. So if we were to do it, I would prefer stub files anyways,
in which case we won't depend on any python version as far as I understood
that.
As Django user, I have to say type hinting would help a lot to understand
how things work in Django without looking at docs. It could save a lot of
time for beginners, too. Also I have to mention, that PyCharm (which is the
most popular IDE for Python, I believe) has support for type hinting and
could help you avoid many problems before even firing up a server.
In my opinion not adding type hints in Django 2.0 would be a mistake.
"Django 2.0 will be the last version of Django to support Python 3.4.
This allows those running older operating systems with Python 3.4 (such as
Ubuntu 14.04 and CentOS 6) to use the latest version of Django for an
additional eight months. If you don't intend to upgrade to a system with
Python 3.5 or later by the end of security updates for Django 2.0 in April
2019, stick with Django 1.11 LTS which is supported until April 2020."
As to Python 3.4 support, Django 1.11 will be LTS and most projects
written with Django <=1.10 will probably stay on LTS version. Using Django
2.0 in existing project would require rewriting some bits anyway (correct
me if I'm wrong), so there's really not much point in sticking to Python
3.4/3.5 in my opinion. If you're rewriting your code to use new version of
Django, you could as well use new version of Python. Isn't it the whole
point of major release?
Sticking to 3.6 would allow using format strings, and that would greatly
increase readability (looking at %-strings here). To be honest, using
str.format on string with many variables can hurt readability almost as
much as % does. Also, variable annotation only appeared in 3.6, so
supporting Python 3.5 an older would mean that variable annotation is only
possible using comments (which is not necessarily a bad thing, tough it has
some downsides as pointed out in PEP-526).
I have to add, that nowadays deploying python applications with desired
version of Python is fairly easy. One could use relocatable virtualenvs,
Docker containers and so on. So even if you're on an outdated distro (or
something like RHEL, that wouldn't get new python version in ages,
probably) and your OS is stuck with older version of Python, your
application doesn't have to be.
Since there're a lot of Django users out there who aren't subscribed to
this mailing list, I suggest to sum up this discussion in a blog post and
let users vote. I believe a big "Help decide Django 2.0 fate" button on
djangoproject.com would attract much more attention to the issue. Maybe
most of Django users are ready to migrate to Python 3.6 when they switch to
Django 2.0 (probably not, but who knows) and developers could start
enjoying new Python features a year or two earlier.
P.S. Please treat everything above as a personal opinion, I'm probably
wrong about some things. And sorry for a bad English, it's not my native
language.
Daniele, here's my try at being more concrete than "It seems reasonable"
and "decent ledge of overlap". Let me know if you meant something different!
"Django 2.0 will be the last version of Django to support Python 3.4.
This allows those running older operating systems with Python 3.4 (such as
Ubuntu 14.04 and CentOS 6) to use the latest version of Django for an
additional eight months. If you don't intend to upgrade to a system with
Python 3.5 or later by the end of security updates for Django 2.0 in April
2019, stick with Django 1.11 LTS which is supported until April 2020."
I'd rather not allow Python 3.4 users to strand themselves on Django 2.0
when sticking with 1.11 would provide longer security support (lesson
learned from Python 2.6 users stranded on Django 1.6), but hopefully
documenting this danger will help prevent that this time around.

Post by Daniele Procida

Post by Florian Apolloner
Not sure on how we'd put that into text, but something along the lines

of

Post by Florian Apolloner
"we will support 3.4+ as long as feasible for us to do so" -- though I

do

Post by Florian Apolloner
understand that this is like the same as saying: "We'll just support

what

Post by Florian Apolloner
we want, how long we want" :D

For the purposes of being reassuring, it needs to be concrete, otherwise
we're just moving people's doubt and uncertainty around!
It seems reasonable that Django 2.0 should continue to support Python
3.4, and that Django 2.1 should not. That provides a decent ledge of
overlap for those climbing up these tricky upgrade paths to rest on and
catch their breath.
Daniele

--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/68cfdafc-730c-42bb-a772-4f17193645f5%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/68cfdafc-730c-42bb-a772-4f17193645f5%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

[Claude Paroz]

Post by Tim Graham
I propose to tentatively target Python 3.5+ for Django 2.0 but not to
remove the current workarounds for Python 3.4 at this time. Shortly before
the alpha for Django 2.0, an interested person can look into how much work
is required to fix any test failures on Python 3.4 and we'll make a
decision then.

I'm strongly advocating for keeping 3.4 support for now, as I would have
difficulty to continue contributing to Django.
My main system is still using 3.4 and will be for some months. Even if I
could rather easily installing manually a more recent Python, I very much
like relying on my stable distro packages. Sorry for my dumbness!

Claude

[Joe Tennies]

I agree that allowing more people to be able to do development against
Django 2.0 is important. That stated, please be very explicit in the
release notes and documentation that "Versions below Python 3.6 are
expected to be dropped before the next Django LTS will be released, so
please keep that in your project planning." (Language too informal, but I
think the idea is correct.)

Post by Claude Paroz

Post by Tim Graham
I propose to tentatively target Python 3.5+ for Django 2.0 but not to
remove the current workarounds for Python 3.4 at this time. Shortly before
the alpha for Django 2.0, an interested person can look into how much work
is required to fix any test failures on Python 3.4 and we'll make a
decision then.

I'm strongly advocating for keeping 3.4 support for now, as I would have
difficulty to continue contributing to Django.
My main system is still using 3.4 and will be for some months. Even if I
could rather easily installing manually a more recent Python, I very much
like relying on my stable distro packages. Sorry for my dumbness!
Claude
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/
msgid/django-developers/09570028-4eea-41ac-b364-
93ae2c946b21%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/09570028-4eea-41ac-b364-93ae2c946b21%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

--
Joe Tennies
***@gmail.com

[Tim Graham]

Ok, I created a ticket to track cleanups and new Python features we can use
when Python 3.4 support is removed:
https://code.djangoproject.com/ticket/27857

We can evaluate that a bit later in the Django 2.0 release cycle and decide
whether or not to keep Python 3.4 support for 1.11.

Post by Joe Tennies
I agree that allowing more people to be able to do development against
Django 2.0 is important. That stated, please be very explicit in the
release notes and documentation that "Versions below Python 3.6 are
expected to be dropped before the next Django LTS will be released, so
please keep that in your project planning." (Language too informal, but I
think the idea is correct.)

Post by Claude Paroz

Post by Tim Graham
I propose to tentatively target Python 3.5+ for Django 2.0 but not to
remove the current workarounds for Python 3.4 at this time. Shortly before
the alpha for Django 2.0, an interested person can look into how much work
is required to fix any test failures on Python 3.4 and we'll make a
decision then.

I'm strongly advocating for keeping 3.4 support for now, as I would have
difficulty to continue contributing to Django.
My main system is still using 3.4 and will be for some months. Even if I
could rather easily installing manually a more recent Python, I very much
like relying on my stable distro packages. Sorry for my dumbness!
Claude
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an
<javascript:>.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/09570028-4eea-41ac-b364-93ae2c946b21%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/09570028-4eea-41ac-b364-93ae2c946b21%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

--
Joe Tennies

[Tim Graham]

With a little more than a month to go until the Django 2.0 alpha (targeted
for September 18), I'd like to make a final decision about whether or not
to keep Python 3.4 support for Django 2.0. Jenkins is currently running the
tests on pull requests with Python 3.4 and 3.6. I've seen a few times where
contributors first used Python 3.5+ syntax and then had to make adjustments
for 3.4 compatibility so while it's not a large burden, it's not a
non-trivial one.

Has anyone changed their thinking in the last few months? If not, I guess
we'll keep Python 3.4 support for Django 2.0 and drop it for 2.1.

Post by Tim Graham
Ok, I created a ticket to track cleanups and new Python features we can
https://code.djangoproject.com/ticket/27857
We can evaluate that a bit later in the Django 2.0 release cycle and
decide whether or not to keep Python 3.4 support for 1.11.

Post by Joe Tennies
I agree that allowing more people to be able to do development against
Django 2.0 is important. That stated, please be very explicit in the
release notes and documentation that "Versions below Python 3.6 are
expected to be dropped before the next Django LTS will be released, so
please keep that in your project planning." (Language too informal, but I
think the idea is correct.)

Post by Claude Paroz

Post by Tim Graham
I propose to tentatively target Python 3.5+ for Django 2.0 but not to
remove the current workarounds for Python 3.4 at this time. Shortly before
the alpha for Django 2.0, an interested person can look into how much work
is required to fix any test failures on Python 3.4 and we'll make a
decision then.

I'm strongly advocating for keeping 3.4 support for now, as I would have
difficulty to continue contributing to Django.
My main system is still using 3.4 and will be for some months. Even if I
could rather easily installing manually a more recent Python, I very much
like relying on my stable distro packages. Sorry for my dumbness!
Claude
--
You received this message because you are subscribed to the Google
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/09570028-4eea-41ac-b364-93ae2c946b21%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/09570028-4eea-41ac-b364-93ae2c946b21%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

--
Joe Tennies

[Florian Apolloner]

Hi Tim,

I've just looked through the list of systems in use here:

* Debian stable: Python 3.5.3
* Ubuntu 16.04 (yes, LTS): 3.5.2
* CentOS 6/7 (and therefore also RHEL): 3.3-3.5 via SCL, 3.3-3.6 via IUS

So all in all dropping 3.4 would be doable. I'd still strongly object to
dropping 3.5.

Cheers,
Florian

Post by Tim Graham
With a little more than a month to go until the Django 2.0 alpha (targeted
for September 18), I'd like to make a final decision about whether or not
to keep Python 3.4 support for Django 2.0. Jenkins is currently running the
tests on pull requests with Python 3.4 and 3.6. I've seen a few times where
contributors first used Python 3.5+ syntax and then had to make adjustments
for 3.4 compatibility so while it's not a large burden, it's not a
non-trivial one.
Has anyone changed their thinking in the last few months? If not, I guess
we'll keep Python 3.4 support for Django 2.0 and drop it for 2.1.

Post by Tim Graham
Ok, I created a ticket to track cleanups and new Python features we can
https://code.djangoproject.com/ticket/27857
We can evaluate that a bit later in the Django 2.0 release cycle and
decide whether or not to keep Python 3.4 support for 1.11.

Post by Joe Tennies
I agree that allowing more people to be able to do development against
Django 2.0 is important. That stated, please be very explicit in the
release notes and documentation that "Versions below Python 3.6 are
expected to be dropped before the next Django LTS will be released, so
please keep that in your project planning." (Language too informal, but I
think the idea is correct.)

Post by Claude Paroz

Post by Tim Graham
I propose to tentatively target Python 3.5+ for Django 2.0 but not to
remove the current workarounds for Python 3.4 at this time. Shortly before
the alpha for Django 2.0, an interested person can look into how much work
is required to fix any test failures on Python 3.4 and we'll make a
decision then.

I'm strongly advocating for keeping 3.4 support for now, as I would
have difficulty to continue contributing to Django.
My main system is still using 3.4 and will be for some months. Even if
I could rather easily installing manually a more recent Python, I very much
like relying on my stable distro packages. Sorry for my dumbness!
Claude
--
You received this message because you are subscribed to the Google
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/09570028-4eea-41ac-b364-93ae2c946b21%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/09570028-4eea-41ac-b364-93ae2c946b21%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

--
Joe Tennies

[Curtis Maloney]

Is there any list of things we gain from dropping / adding any particular version?

The older discussion mentions a tracking ticket, but it is empty.

--
C

Post by Tim Graham
With a little more than a month to go until the Django 2.0 alpha (targeted
for September 18), I'd like to make a final decision about whether or not
to keep Python 3.4 support for Django 2.0. Jenkins is currently running the
tests on pull requests with Python 3.4 and 3.6. I've seen a few times where
contributors first used Python 3.5+ syntax and then had to make
adjustments
for 3.4 compatibility so while it's not a large burden, it's not a
non-trivial one.
Has anyone changed their thinking in the last few months? If not, I guess
we'll keep Python 3.4 support for Django 2.0 and drop it for 2.1.

Post by Tim Graham
Ok, I created a ticket to track cleanups and new Python features we

can

Post by Tim Graham
https://code.djangoproject.com/ticket/27857
We can evaluate that a bit later in the Django 2.0 release cycle and
decide whether or not to keep Python 3.4 support for 1.11.

Post by Joe Tennies
I agree that allowing more people to be able to do development

against

Post by Tim Graham

Post by Joe Tennies
Django 2.0 is important. That stated, please be very explicit in the
release notes and documentation that "Versions below Python 3.6 are
expected to be dropped before the next Django LTS will be released,

so

Post by Tim Graham

Post by Joe Tennies
please keep that in your project planning." (Language too informal,

but I

Post by Tim Graham

Post by Joe Tennies
think the idea is correct.)

Post by Claude Paroz

Post by Tim Graham
I propose to tentatively target Python 3.5+ for Django 2.0 but not

to

Post by Tim Graham

Post by Joe Tennies

Post by Claude Paroz

Post by Tim Graham
remove the current workarounds for Python 3.4 at this time.

Shortly before

Post by Tim Graham

Post by Joe Tennies

Post by Claude Paroz

Post by Tim Graham
the alpha for Django 2.0, an interested person can look into how

much work

Post by Tim Graham

Post by Joe Tennies

Post by Claude Paroz

Post by Tim Graham
is required to fix any test failures on Python 3.4 and we'll make

a

Post by Tim Graham

Post by Joe Tennies

Post by Claude Paroz

Post by Tim Graham
decision then.

I'm strongly advocating for keeping 3.4 support for now, as I would

have

Post by Tim Graham

Post by Joe Tennies

Post by Claude Paroz
difficulty to continue contributing to Django.
My main system is still using 3.4 and will be for some months. Even

if I

Post by Tim Graham

Post by Joe Tennies

Post by Claude Paroz
could rather easily installing manually a more recent Python, I

very much

Post by Tim Graham

Post by Joe Tennies

Post by Claude Paroz
like relying on my stable distro packages. Sorry for my dumbness!
Claude
--
You received this message because you are subscribed to the Google
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it,

send

Post by Tim Graham

Post by Joe Tennies

Post by Claude Paroz
Visit this group at

https://groups.google.com/group/django-developers.

Post by Tim Graham

Post by Joe Tennies

Post by Claude Paroz
To view this discussion on the web visit

https://groups.google.com/d/msgid/django-developers/09570028-4eea-41ac-b364-93ae2c946b21%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/09570028-4eea-41ac-b364-93ae2c946b21%40googlegroups.com?utm_medium=email&utm_source=footer>

Post by Tim Graham

Post by Joe Tennies

Post by Claude Paroz
.
For more options, visit https://groups.google.com/d/optout.

--
Joe Tennies

--
You received this message because you are subscribed to the Google
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send
To post to this group, send email to
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/356d7e07-0be0-4200-a5da-0d092dd2e761%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[Tom Forbes]

One of the biggest gains would be allowing third party packages to begin to
add type hints, if we support 3.4 this won't happen for a while at least.

Other gains, for Django and third party packages include:
- code improvements using unpacking generalizations
- speed improvements with OrderedDict and lru_cache
- support for the Http status enumeration in stdlib
- much faster directory iteration function with scandir
- other general speed improvements (
https://docs.python.org/3/whatsnew/3.5.html#optimizations)

Apart from type hinting (which is a contentious issue) there are not any
big gains we get from 3.5 over 3.4. lots of small ones though.

On 8 Aug 2017 09:16, "Curtis Maloney" <***@tinbrain.net> wrote:

Is there any list of things we gain from dropping / adding any particular
version?

The older discussion mentions a tracking ticket, but it is empty.

--
C

Post by Tim Graham
With a little more than a month to go until the Django 2.0 alpha (targeted
for September 18), I'd like to make a final decision about whether or not
to keep Python 3.4 support for Django 2.0. Jenkins is currently running the
tests on pull requests with Python 3.4 and 3.6. I've seen a few times where
contributors first used Python 3.5+ syntax and then had to make adjustments
for 3.4 compatibility so while it's not a large burden, it's not a
non-trivial one.
Has anyone changed their thinking in the last few months? If not, I guess
we'll keep Python 3.4 support for Django 2.0 and drop it for 2.1.

Post by Tim Graham
Ok, I created a ticket to track cleanups and new Python features we can
use when Python 3.4 support is removed: https://code.djangoproject.com
/ticket/27857
We can evaluate that a bit later in the Django 2.0 release cycle and
decide whether or not to keep Python 3.4 support for 1.11.

Post by Joe Tennies
I agree that allowing more people to be able to do development against
Django 2.0 is important. That stated, please be very explicit in the
release notes and documentation that "Versions below Python 3.6 are
expected to be dropped before the next Django LTS will be released, so
please keep that in your project planning." (Language too informal, but I
think the idea is correct.)

Post by Claude Paroz

Post by Tim Graham
I propose to tentatively target Python 3.5+ for Django 2.0 but not to
remove the current workarounds for Python 3.4 at this time. Shortly before
the alpha for Django 2.0, an interested person can look into how much work
is required to fix any test failures on Python 3.4 and we'll make a
decision then.

I'm strongly advocating for keeping 3.4 support for now, as I would
have difficulty to continue contributing to Django.
My main system is still using 3.4 and will be for some months. Even if
I could rather easily installing manually a more recent Python, I very much
like relying on my stable distro packages. Sorry for my dumbness!
Claude
--
You received this message because you are subscribed to the Google
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/ms
gid/django-developers/09570028-4eea-41ac-b364-93ae2c946b21%
40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/09570028-4eea-41ac-b364-93ae2c946b21%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

--
Joe Tennies

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to django-developers+***@googlegroups.com.
To post to this group, send email to django-***@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/
msgid/django-developers/6160B82D-223A-401F-BB3C-B87965C83823%40tinbrain.net
<https://groups.google.com/d/msgid/django-developers/6160B82D-223A-401F-BB3C-B87965C83823%40tinbrain.net?utm_medium=email&utm_source=footer>
.

For more options, visit https://groups.google.com/d/optout.

[Claude Paroz]

Post by Tim Graham
Has anyone changed their thinking in the last few months? If not, I guess
we'll keep Python 3.4 support for Django 2.0 and drop it for 2.1.

I am not strongly opposed to dropping 3.4 support, but I still think we
should keep it for Django 2.0.
The speed improvements in 3.5/3.6 are still available if you run more
recent versions in your own projects.
I have not yet read any compelling reason to drop Python 3.4 support now.

Claude

[Aymeric Augustin]

Hello,

I took a look at this thread again and I still reach the same conclusion as Claude.

Best regards,
--
Aymeric.

Has anyone changed their thinking in the last few months? If not, I guess we'll keep Python 3.4 support for Django 2.0 and drop it for 2.1.
I am not strongly opposed to dropping 3.4 support, but I still think we should keep it for Django 2.0.
The speed improvements in 3.5/3.6 are still available if you run more recent versions in your own projects.
I have not yet read any compelling reason to drop Python 3.4 support now.
Claude
--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
Visit this group at https://groups.google.com/group/django-developers <https://groups.google.com/group/django-developers>.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/7d30960d-41d8-4864-b749-dfa62810ed39%40googlegroups.com <https://groups.google.com/d/msgid/django-developers/7d30960d-41d8-4864-b749-dfa62810ed39%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

[Joe Tennies]

Looking at the list, I think the only gain that required 3.5+ was typing.
The performance was due to which version was installed and not a real
feature. That stated, should the installer add typing from pypi as a
requirement (assuming someone adds typing info).

On Wed, Aug 9, 2017, 3:01 AM Aymeric Augustin <

Post by Aymeric Augustin
Hello,
I took a look at this thread again and I still reach the same conclusion as Claude.
Best regards,
--
Aymeric.

Post by Tim Graham
Has anyone changed their thinking in the last few months? If not, I guess
we'll keep Python 3.4 support for Django 2.0 and drop it for 2.1.

I am not strongly opposed to dropping 3.4 support, but I still think we
should keep it for Django 2.0.
The speed improvements in 3.5/3.6 are still available if you run more
recent versions in your own projects.
I have not yet read any compelling reason to drop Python 3.4 support now.
Claude
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/7d30960d-41d8-4864-b749-dfa62810ed39%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/7d30960d-41d8-4864-b749-dfa62810ed39%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/16F0CFA9-6AE8-457D-A07D-50630DE36BD5%40polytechnique.org
<https://groups.google.com/d/msgid/django-developers/16F0CFA9-6AE8-457D-A07D-50630DE36BD5%40polytechnique.org?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

[Tim Graham]

Here's a PR to document Python 3.4 support for Django 2.0:
https://github.com/django/django/pull/8884

Post by Joe Tennies
Looking at the list, I think the only gain that required 3.5+ was typing.
The performance was due to which version was installed and not a real
feature. That stated, should the installer add typing from pypi as a
requirement (assuming someone adds typing info).
On Wed, Aug 9, 2017, 3:01 AM Aymeric Augustin <

Post by Aymeric Augustin
Hello,
I took a look at this thread again and I still reach the same conclusion as Claude.
Best regards,
--
Aymeric.

Post by Tim Graham
Has anyone changed their thinking in the last few months? If not, I
guess we'll keep Python 3.4 support for Django 2.0 and drop it for 2.1.

I am not strongly opposed to dropping 3.4 support, but I still think we
should keep it for Django 2.0.
The speed improvements in 3.5/3.6 are still available if you run more
recent versions in your own projects.
I have not yet read any compelling reason to drop Python 3.4 support now.
Claude
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an
<javascript:>.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/7d30960d-41d8-4864-b749-dfa62810ed39%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/7d30960d-41d8-4864-b749-dfa62810ed39%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an
<javascript:>.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/16F0CFA9-6AE8-457D-A07D-50630DE36BD5%40polytechnique.org
<https://groups.google.com/d/msgid/django-developers/16F0CFA9-6AE8-457D-A07D-50630DE36BD5%40polytechnique.org?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

[Alex Krupp]

One platform that only supports up to Python 3.4 ElasticBeanstalk with
Amazon Linux. A few months ago they said they were going to release a new
AMI, but that hasn't happened yet.

I'm personally happy seeing support for 3.4 dropped and possibly just
waiting a few months to upgrade to Django 2.0. But the staff at the AWS
popup lofts have been saying that they look at the number of support
tickets in deciding when to cut new AMI releases, so if other people care
about this then maybe it would be a good time to start filing tickets.

Post by Tim Graham
When I drafted the 1.11 release notes in May, I wrote, "The next major
release, Django 2.0, will only support Python 3.5+."
Our Python version support policy is "Typically, we will support a Python
version up to and including the first Django LTS release whose security
support ends after security support for that version of Python ends."
Python 3.5's EOL is September 2020 which I think is sufficiently close to
Django 1.11's EOL of April 2020 that we could say Django 2.0 is Python
3.6+. The alternative is not to drop Python 3.5 compatibility until Django
2.2 LTS which is supported until April 2022. I don't see much advantage to
that. Any objections?
p.s. There is already a ticket suggesting to take advantage of a Python
https://code.djangoproject.com/ticket/27635* - *django.utils.crypto
should use secrets on Python 3.6+