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.

[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

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

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

[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

[Florian Apolloner]

Hi,

On Sunday, January 8, 2017 at 8:43:46 AM UTC+1, roboslone wrote:

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

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.
 

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)
 

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.
 

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…
 

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.
 

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

[Florian Apolloner]

Hi Josh,

On Sunday, January 8, 2017 at 11:38:52 AM UTC+1, Josh Smeaton wrote:

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.

 

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

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

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

[Claude Paroz]

Le mardi 17 janvier 2017 15:48:46 UTC+1, Tim Graham a écrit :

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

--

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/09570028-4eea-41ac-b364-93ae2c946b21%40googlegroups.com.

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

--

Joe Tennies
ten...@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.

On Wednesday, January 18, 2017 at 12:20:13 PM UTC-5, Rotund wrote:

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

On Wed, Jan 18, 2017 at 2:28 AM, Claude Paroz <cla...@2xlibre.net> wrote:

Le mardi 17 janvier 2017 15:48:46 UTC+1, Tim Graham a écrit :

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 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/09570028-4eea-41ac-b364-93ae2c946b21%40googlegroups.com.

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

--

Joe Tennies
ten...@gmail.com

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

[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

[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

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

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/6160B82D-223A-401F-BB3C-B87965C83823%40tinbrain.net.

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

On Tuesday, December 27, 2016 at 10:12:57 AM UTC-5, 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+

[Claude Paroz]

Le mardi 8 août 2017 01:45:55 UTC+2, Tim Graham a écrit :

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.

--
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/7d30960d-41d8-4864-b749-dfa62810ed39%40googlegroups.com.

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

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/16F0CFA9-6AE8-457D-A07D-50630DE36BD5%40polytechnique.org.

[Tim Graham]

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