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

[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

[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

--
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+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@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/f1da2b09-0309-46e6-9a7c-75ea9cd6f91b%40googlegroups.com.
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. 

On Tuesday, December 27, 2016 at 4:37:06 PM UTC-5, MMeent wrote:

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

On 27 Dec 2016 21:25, "Florian Apolloner" <f.apo...@gmail.com> wrote:

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

On Tuesday, December 27, 2016 at 4:12:57 PM UTC+1, Tim Graham wrote:

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+

--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.

[Michael Manfre]

On Tue, Dec 27, 2016 at 3:52 PM Tim Graham <timog...@gmail.com> wrote:

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.

 

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!

[Aymeric Augustin]

> On 28 Dec 2016, at 15:53, Claude Paroz <cla...@2xlibre.net> wrote:
>
> 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.

[Karen Tracey]

On Wed, Dec 28, 2016 at 2:41 PM, Claude Paroz <cla...@2xlibre.net> wrote:

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]

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

[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.

[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 

[Florian Apolloner]

Hi Asif,

On Thursday, January 5, 2017 at 9:10:40 PM UTC+1, Asif Saifuddin wrote:

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

[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


On Tuesday, December 27, 2016 at 4:12:57 PM UTC+1, Tim Graham wrote:

[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]

On Fri, Jan 6, 2017, Florian Apolloner <f.apo...@gmail.com> wrote:

>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?

[Tom Evans]

On Thu, Jan 5, 2017 at 8:10 PM, Asif Saifuddin <auv...@gmail.com> wrote:
> 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

[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?

[James Bennett]

On Fri, Jan 6, 2017 at 7:03 PM Tim Graham <timog...@gmail.com> wrote:

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.

--

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+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@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/680d3d55-a9d4-46d9-a587-c49649f24cbf%40googlegroups.com.

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

--

Daniel F. Moisset - UK Country Manager

www.machinalis.com

Skype: @dmoisset

[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

[Daniele Procida]

On Sat, Jan 7, 2017, Florian Apolloner <f.apo...@gmail.com> wrote:

>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

[Florian Apolloner]

On Saturday, January 7, 2017 at 4:03:43 AM UTC+1, Tim Graham wrote:

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.

[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.

[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.

--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@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/68cfdafc-730c-42bb-a772-4f17193645f5%40googlegroups.com.