revisiting the Python version support policy

[Tim Graham]

When deciding when to drop support for Python 2 in Django, there was consensus to adopt this Python version support policy [0]: "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. For example, Python 3.3 security support ends September 2017 and Django 1.8 LTS security support ends April 2018. Therefore Django 1.8 is the last version to support Python 3.3."

Since then, we didn't abide by this policy when dropping Python 3.4, mainly because Debian stable still used Python 3.4 at the time and Claude argued that some people like him would have difficulty contributing to Django if they had to install another version of Python [1].

Based on the policy, it's time to drop support for Python 3.5 in the master branch (Django 3.0) -- with Django 2.2 LTS supported until April 2022 and Python 3.5 supported until September 2020). I created a ticket [2] and PR [3] for dropping support for Python 3.5 [2], however, Claude commented, "I'm not so enthusiast to drop Python 3.5 now (it is still the default version in Debian stable). Couldn't this be done in Django 3.1 instead?"

Are you in favor of amending the Python support version policy to account for the Python version in Debian stable?

[0] https://docs.djangoproject.com/en/dev/faq/install/#what-python-version-can-i-use-with-django

[1] https://groups.google.com/d/msg/django-developers/4rbVKJYm8DI/TTh3i04pBQAJ

[2] https://code.djangoproject.com/ticket/30116

[3] https://github.com/django/django/pull/10864

[Ryan Hiebert]

I don't feel like my voice should have much weight, but I think that the policy as written is better. Debian aims to be stable long term, and for us to match Debian, especially when not in our LTS releases, seems excessive to me.

--
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/ce5f3cdb-a623-4bcc-a661-bf88d91a5a7f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jason Johns]

In addition, with tools like https://github.com/pyenv/pyenv available that make changing the currently applicable python version in any given shell extremely easy, I feel pinning support to a specific operating system version, however stable, is not the optimal approach

[Claude Paroz]

I understand my obsession for stable software puts me in a small-minority group and I would not like to be an obstacle for all other Django users and developers.

Let's stick to the current policy. I'll try to remember that and prevent commenting on the next " Drop python support..." ticket :-)

Claude

[Adam Johnson]

I like stability too, but I think Django's current policy is useful for driving the ecosystem forwards. Users sticking on old/stable versions of Python can stick on old/stable versions of Django :)

--

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/85adb894-c908-4835-98fe-96c859d79a15%40googlegroups.com.

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

--

Adam

[Federico Capoano]

I would ask: what are the pros and cons of dropping support for python 3.5?

I think allowing users to easily use and install django based applications is more important than strictly follow a python version support policy.

I think that if we drop support for python 3.5, which is the default python version on many linux platforms right now, we will make the life of our users and developers harder.

I don't understand the reason for doing so, if we have to do it for a good reason, like a security issue, or because django has to take advantage of features that are available only from python 3.6 onwards, I would be in favour, but if we have to do it only because the policy says so, without any other advantage, I would amend the policy.

My 2 cents.

Thanks for your hard work maintaining django

Federico 

[Collin Anderson]

Now that we've dropped Python 2, I personally wouldn't mind having the policy be to support all supported versions of python (except 2.7) at the time of each Django release. So Django would drop just after Python drops. (The most recent version of Django (and maybe LTS too) should probably also add support for new versions of Python, so we're not holding people back from trying out the latest Python.) But I don't have a good feel for what the maintenance burden is for supporting old versions of Python, so I don't see first-hand the advantages of dropping earlier. Now that we're 3.x-only, I don't like the idea of "driving the ecosystem forwards" being an excuse for dropping Python early. I agree "allowing users to easily use and install django based applications" is more important.

I also like the idea of "amending the Python support version policy to account for the Python version in Debian stable", as that's a little more practical, though we start play favorites with distros.

--

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/51dfc517-8b5a-4803-9f8d-daa1bf920e7b%40googlegroups.com.

[Gert Van Gool]

We can look at the larger distros (Debian, Ubuntu, RHEL). For RHEL, their derivatives include CentOS , Scientic Linux, Amazon Linux, Oracle Linux. RHEL 7 has no (main) Python 3 support. It's only introduced in RHEL 8 (which is currently in beta).

That gives us for Debian Stretch (stable) and Ubuntu 16.04 Python 3.5. While Ubuntu 18.04 and RHEL 8 have Python 3.6. 

-- Gert

Mobile: +32 498725202

Twitter: @gvangool
Web: http://gertvangool.be

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFO84S5kx5W18xA7H99cJk9%2B7s4LVRNJCD7RDfaXBz76HjEAQQ%40mail.gmail.com.

[Josh Smeaton]

Don't discount being able to use features from newer versions of python within Django itself.

https://docs.python.org/3/whatsnew/3.6.html

- dicts are more performant

- dicts/kwargs/class attributes are ordered (cpython implementation detail for 3.6 - allowing us to consider removing descriptor counters)

- fstrings

- type annotations (something some people are quite in favour of)

- async comprehensions and generators (less important for Django right now - may be more important for Channels)

- secrets module

- pathlib

- descriptor improvements (set_name, __init_subclass__)

I'm more in favour of maintaining the existing policy than playing favourites with distro support, but not strongly so. The LTS Django is already covering Python 3.5 for 18 months **longer** than the EOL. I don't think the newest versions of Django need to be so concerned with distro compatibility.

[James Bennett]

I worry about the precedent we'd set if we made an exception for Debian, because the next question would be "OK, can we have an exception for Red Hat, too?" Keep in mind Red Hat currently sells up to fourteen years of support for their RHEL platform.

So I think it's best to recognize that:

People who just want to use Django, and choose to prioritize long-lived stable operating-system distributions, will get a supported version of Django from their operating-system vendor (and the vendor will maintain that version of Django for the length of the vendor's support period). They don't get to use newer versions of Django that drop support for their vendor's default Python version, but they've already made the choice to prioritize stability rather than access to new versions, and this is the consequence of the choice.

People who want to contribute to Django probably already need to solve the problem of having multiple Python versions installed, since we don't have any releases that are tied to only one version of Python. So they need to use something other than their system's default Python no matter what, and dropping support for an older system Python doesn't add any complications to their workflow.

So I don't think we should make an exception for Debian, or any other long-lived distributions.

[Joe Tennies]

I'm not going to argue one way or the other, as it doesn't really affect me either way. (I will say that Python 3.5 is no longer a supported version on Heroku.)

On the other hand, I will argue how supporting 3.5 might affect the upcoming Django version. I've included my opinionated breakdown below. I will say that the biggest item I see is the security in django/utils/crypto.py. It could get rid of the less than ideal fallback and just use secrets for the RNG. The descriptor improvements may be important, but I couldn't tell.

On Tue, Jan 22, 2019 at 11:16 PM Josh Smeaton <josh.s...@gmail.com> wrote:

Don't discount being able to use features from newer versions of python within Django itself.

https://docs.python.org/3/whatsnew/3.6.html

- dicts are more performant

This should just make 3.6 faster, right? It doesn't actually break 3.5.

- dicts/kwargs/class attributes are ordered (cpython implementation detail for 3.6 - allowing us to consider removing descriptor counters)

According to the documentation you posted, this is not to be relied upon (until 3.7 that is).

- fstrings

 While this is interesting, I must state that I'm more than a little concerned of the security implications for grabbing variables from the global memory space.

- type annotations (something some people are quite in favour of)

According to the documentation, these changes were backported to 3.5, though saying you need 3.5.x where x> something is... painful to support. Also, unlikely to make it in this version of Django. They are also much more useful in 3.7 when PEP 563 is implemented to allow for forward declarations and not evaluating them at startup (though this will require a __future__ import even then).

- async comprehensions and generators (less important for Django right now - may be more important for Channels)

 Agreed, and perhaps Channels has a higher requirement. I'll also point out async improvements and usability is also in the Python 3.7 release notes.

- secrets module

This could be a security concern that should at least be documented. It is solely a cryptographically sound random number generator currently.

- pathlib

 This would be interesting to add support for.

- descriptor improvements (set_name, __init_subclass__)

I'm not sure I'm smart enough to understand this... at least at this point in the night.

I'm more in favour of maintaining the existing policy than playing favourites with distro support, but not strongly so. The LTS Django is already covering Python 3.5 for 18 months **longer** than the EOL. I don't think the newest versions of Django need to be so concerned with distro compatibility.

--

Joe Tennies
ten...@gmail.com

[Claude Paroz]

Le mercredi 23 janvier 2019 08:31:17 UTC+1, James Bennett a écrit :

I worry about the precedent we'd set if we made an exception for Debian, because the next question would be "OK, can we have an exception for Red Hat, too?" Keep in mind Red Hat currently sells up to fourteen years of support for their RHEL platform.

You're right, the fact that this is Debian or any other distro doesn't matter here. My idea was to set the policy as : when a new major Django version is released, it supports all current supported versions of Python.

> People who want to contribute to Django probably already need to solve the problem of having multiple Python versions installed...

That's not my experience. It was during Python 2/3 coexistence, but now if you develop with any Python 3 version, the rare cases where Python version incompatibilities happen are catched by the CI runs.

Claude

[Carlton Gibson]

> My idea was to set the policy as : when a new major Django version is released, it supports all current supported versions of Python.

I agree with this — more or less...

Python 3.5 is officially supported for the entire life of Django 3.0. (It goes EOL a month after Django 3.0) 

(c.p [0] vs [1])

[0]: https://devguide.python.org/#status-of-python-branches

[1]: https://www.djangoproject.com/download/#supported-versions

So I think we SHOULD support Python 3.5 for Django 3.0.

(Yes, push forward, but pushing people off of supported versions seems a bit over-zealous, and I think we'll be shooting ourselves in the foot, due to the need to repeatedly handle, probably valid, pushback.)

However Django v3.1 will be released JUST A MONTH before Python v3.5 goes EOL. As such I don't want to support it there. 

So, phrasing... maybe... as a draft: "Typically, we will support a Python version unless it will be end of life before the corresponding version of Django is outside of mainstream support. For example, Python 3.5 security support ends September 2019, whilst Django 3.1 ends mainstream support in April 2021. Therefore Django 3.0, which is end of life August 2019 is the last version to support Python 3.5." 

i.e. What Claude said except "...unless it's just about to be dropped". 

I know we backported support for Python 3.7 to Django 1.11 but I think this should apply to the LTS as well. 

> ...they've already made the choice to prioritize stability rather than access to new versions, and this is the consequence of the choice...

Just as an additional point, Django third-party apps as a rule try to follow Django's support versions policy. (i.e. Currently supporting 1.11+) This works well for people. I think the situation is equivalent with regards to Django and Python. 

Kind Regards,

Carlton

[Carlton Gibson]

Sorry I mistyped. " Python 3.5 security support ends September 2020" (but you get the point.)

[Adam Johnson]

So, phrasing... maybe... as a draft: "Typically, we will support a Python version unless it will be end of life before the corresponding version of Django is outside of mainstream support. For example, Python 3.5 security support ends September 2019, whilst Django 3.1 ends mainstream support in April 2021. Therefore Django 3.0, which is end of life August 2019 is the last version to support Python 3.5." 

+1. A subtle change on the existing policy but it makes a difference.

On Thu, 24 Jan 2019 at 08:16, Carlton Gibson <carlton...@gmail.com> wrote:

Sorry I mistyped. " Python 3.5 security support ends September 2020" (but you get the point.)

--

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/ac50c67c-51a8-4c94-9505-c19fc6fd7cfc%40googlegroups.com.

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

--

Adam

[Ryan Hiebert]

On Thu, Jan 24, 2019 at 10:55 AM Adam Johnson <m...@adamj.eu> wrote:

So, phrasing... maybe... as a draft: "Typically, we will support a Python version unless it will be end of life before the corresponding version of Django is outside of mainstream support. For example, Python 3.5 security support ends September 2019, whilst Django 3.1 ends mainstream support in April 2021. Therefore Django 3.0, which is end of life August 2019 is the last version to support Python 3.5." 

+1. A subtle change on the existing policy but it makes a difference.

That seems better to me as well. It only ties us to the support policy of Python, not various special-cased distributions. My concern, though, is that it weakens semantic versioning a bit, so we should do it carefully. We don't follow it precisely, but if we drop support for a version of Python, that seems to me like it would qualify as a breaking change, and should be preferred to be done when changing major versions after an LTS release. If that is deemed to not be a significant concern, then I think this proposed policy is a reasonable one.

[Tim Graham]

It's interesting to me that no one (besides Claude -- and that's based on his ability to contribute to Django) has indicated that they care about Python 3.5 support in their deployments of Django 3.0... so I wonder if there is really a strong need for it. Who is saying, "I want to use the latest version of Django, but I want to use a really old version of Python." ... then 8 months later when Django 3.1 is released ... oh, now I still want to use the latest version of Django but I can't because my Python is too old.

It's an analogous situation to Django 2.0 and Python 3.4. From the Django 2.0 release notes, "Django 2.0 will be the last release series to support Python 3.4. If you plan a deployment of Python 3.4 beyond the end-of-life for Django 2.0 (April 2019), stick with Django 1.11 LTS (supported until April 2020) instead. Note, however, that the end-of-life for Python 3.4 is March 2019." Is anyone in this situation? As I argued before, I think it's better to drop support for versions of Python after an LTS so that Django users aren't "stranded" on some unsupported Django because their Python is too old.

If we amend the policy as suggested, then I think Django 2.1 (end of mainstream support in April) would have gotten Python 3.4 support (end of support in March) -- did anyone miss that?

It's impossible to quantify how much work would be required to support the oldest version of Python an extra 8 or 16 months in Django's branch. It's not only keeping around workarounds for that older Python, but also developing new features with workarounds... and not being able to use new features in Python (or having to vendor them in Django, which then generally requires a deprecation of that vendored code). I think the justification to adopt a new policy should be clear. Currently I see "it would be nice" theoretical arguments. Let's hear from people who find the current Python support policy insufficient for their needs.

[Ryan Hiebert]

On Thu, Jan 24, 2019 at 11:29 AM Tim Graham <timog...@gmail.com> wrote:

Let's hear from people who find the current Python support policy insufficient for their needs.

Agreed. I'm not one of them, dropping 3.5 support disadvantages me in no way. I don't use it in production or in development, and would have no problem with 3.5 support being dropped.

[Carlton Gibson]

To be honest, I'm surprised there's even one person who comes within a 1000 miles of this list who's using Python 3.5. :)

My reason for thinking we should follow Python's supported versions is users, and particularly beginning users, who have got they-don't-know version and find a tutorial just what... no sorry need... `pip3 install Django` to work, and give them the version of Django that corresponds to what they see when they visit docs.djangoproject.com. 

I don't agree this is theoretical at all. 

It's not just Debian. (Which doesn't fit my mental model here really...)

It's all those few-years-old computers out there. 

It's for example Raspbian, which as of this month is still shipping Python 3.5. 

So my boy, who's 10, says, 

- What would you use? 

- Well I'd use Django (obviously) 

- Can I use that?

- Yeah... 

If we do drop Python 3.5 I have to say, "Well, no. But you can use this old one." That's not as cool.

But there will be people who are more seriously affected. 

> Who is saying, "I want to use the latest version of Django, but I want to use a really old version of Python."

No one is saying this. The notion of versions doesn't come into it. We're well beyond the barrier-to-entry before we get there. 

I (just my opinion on this) think we mistake our audience if we forget this.  

(For this reason I don't think the deployment issue is the relevant one. It's about people learning to programme, not professionals.) 

We can't support everything forever, and I'm as keen as anyone to push forward, but following Python is (for me) the thing we should do. 

I think Django's position in the Python eco-system requires it. 

Of course if we don't, things are easier for us, yes. 

Again, just my opinion. 

C. 

[Tom Forbes]

This message really resonated with me, especially after helping a few beginners get started with Python and watching them struggle with exactly this kind of thing.

I'd be +1 on following Python. Looking through the diff there is not a huge amount of things to remove and IMO none of them are really holding us back or all that serious. We've fixed some issues with mangling cached property names, some workarounds for ModuleNotFoundError/ImportError and an issue with sqlite3 on 3.5.

--
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/19e099cf-6087-4efd-9138-d338f12bbf2c%40googlegroups.com.

[Tim Graham]

`pip install Django` gives the latest version of Django that's compatible for the current version of Python. Yes, users will have to switch versions at docs.djangoproject.com and they'll be in the same situation at docs.python.org if they're using Python 3.5. For learning Django, I'd think the latest LTS should be just fine. I get the sense that many intro to Django books are  updated at each LTS release.

At this point, I don't see much consensus so I think the default course of action would be to stick with the current policy unless someone wants to ask the technical board to vote upon the new proposal.

For what it's worth, there's a new test failure after a recent patch due to non-deterministic dict ordering in Python 3.5 which demonstrates the sort of minor annoyances that take time away from making useful improvements to Django.

[Dan Davis]

My employer is still using CPython 3.4.6 on the servers, and CPython 3.5.1 on the desktop.   I've been instrumental in developing a plan to move forward.  I know of one established company and one start-up, by name, where they are still using CPython 2.7 (and a horrendously old version of Django), because it is hard to upgrade.   As long as Django has a LTS version, such as 1.11, and soon 2.2, I think forcing an upgrade is OK.   But it is good to be aware of what's out there.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFNZOJPdaWYJ9LCPZsG9dE66ka%2B8M_8Y4_%2BzMwFNz4er1pXi8w%40mail.gmail.com.

[Tim Graham]

Can you explain more about what they struggled with? Maybe there's other ways to solve those problems.

[Florian Apolloner]

FWIW, most of my problems with python version dependencies went away when I started to use a custom build on our servers. Allows easy upgrades and a good environment for our programs.

[Joe Tennies]

I just want to recap what I'm hearing.

After listening to the arguments, it doesn't sound like many seasoned developers/Django users would need the 3.5 support to remain for development purposes. Therefore, their needs don't seem to need to be considered.

Larger organizations may have issues with Enterprise/LTS Linux distros not having that version of Python by default for deploying. This is not a top concern, but it is at least a slight concern.

Beginning and unseasoned Django users can be easily confused by choices. This has been the focus of much of this discussion. This seems to be a pretty major concern. Is there a way that we deal with this? I have some suggestions below.

I am not sure that that last issue can be as easily solved by technical solutions as much as social/documentation solutions. Therefore, I'm going to point out some things that I'm noticing.

First, the main Django webpage only mentions the very latest release. I think that this should be updated to more prominently show the latest LTS release. It should also show all currently supported releases underneath it.

Secondly, should we be suggesting that beginners stick to the latest LTS version? I think this makes sense as there should be better documentation and people will not have to deal as much with just general churn. This leads into "how would a beginner get the latest LTS version?" Let's assume they understand pip. Is there a way for them to get pinned to the latest Django LTS release? Should Django have a package in pypi named django-lts that is just a dummy package that has a dependency of django>=1.11.0,<2.0? Would this break on a pip update that would update all packages? I'm trying to think of any scenarios where someone could jump off an LTS accidentally without doing something completely wrong.

Thirdly, if we do push people towards the LTS releases, should docs.djangoproject.com default to the latest LTS version instead of the latest release (whether LTS or not)?

Fourthly, I think the documentation should more clearly state what version of Python it supports. I'm looking at the 2.1 documentation (current thing a beginner would see), and I don't see it. It's not on the first half of the main page, nor the install instructions. I do see a suggestion for "lastest version" (which may not be supported yet if right after a new Python release -- too new) or "use OS's package manager (which we just stated would not be new enough if using a more stable distro -- too old).

That ends my thoughts on the unseasoned Django user, but I had a potential concern that I hadn't heard brought up. Is there any added effort as far as deploying to a non-system version of Python? I have an odd deployment on Dreamhost that uses passenger to deploy my Django apps. I have to do a weird passenger_wsgi.py file as mentioned in https://help.dreamhost.com/hc/en-us/articles/360002341572-How-to-create-a-Django-2-project-using-virtualenv that changes the Python interpreter on the fly. Does that affect something like mod_wsgi, uwsgi, gunicorn, or some other wsgi runner? I mean if it would come down to recompiling Apache or some such, that would put a fair amount of burden on someone to deploy. If it stays generally separate then it's fine.

Assuming the deployment issue is "only in rare/corner cases" or less, I think the grand majority of the concerns could be fixed through documentation and website updates.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/c25bb851-f334-48d4-bdd4-470c0ff10e2c%40googlegroups.com.

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

--

Joe Tennies
ten...@gmail.com

[Carlton Gibson]

I worry about us making this kind of decision in the rarified air of the developer mailing list. It's a technical question yes, but it affects the entire community. 

I think, here, we underplay just how hard it is for people out there. IMO expecting that people suffering from massive information overload to successfully switch docs version is already setting the bar too high. People really struggle. 

I'll give you one concrete example. 

Teaching DjangoGirls in Barcelona, one student—presumably for EXACTLY the kind of version mis-match we're talking about here—had her project created with a different version of the template than everybody else's. It didn't have contrib.staticfiles in INSTALLED_APPS. As such, where everyone else was able to deploy, her deployment failed. In the end there were instructors from three tables around here laptop trying who-knows-what in the shell before it was worked out and resolved. ("Try `collectstatic` locally" led to the answer.) 

Without those instructors present that student would have been stuck at that point, and lost. 

I don't have figures, and we never hear from most of these people, but I guess this sort of difficulty happens a lot. 

A quick scan of django-users suggests it's all the time. 

> ...there's a new test failure after a recent patch due to non-deterministic dict ordering in Python 3.5 which demonstrates the sort of minor annoyances that take time away from making useful improvements to Django.

It's not that I don't hear you hear. I do. 

It's just that I think of this as an accessibility issue, and accessibility is a feature too. 

For me, if the cost of including someone is that we have to use OrderedDict for a wee-bit longer, then so be it. 

Kind Regards,

Carlton

[Joe Tennies]

Carlton,

I read your response, and I think what you said is very important. I would like to ask you a few questions, if you don't mind. I'm not trying to back you into a corner; I'm trying to understand what you see with your teaching and getting insight from that.

Do you think it makes sense to have beginners working off non-LTS versions? Personally, I think the LTS is the version that beginner's should run. They're "real" projects are likely to take longer, and they aren't going to want to track the latest and greatest. I also think that any non-LTS version of the docs should have a similar heading to the dev version to suggest that beginners likely would benefit from using the latest LTS version.

How many people coming to your trainings are running a stable/enterprise Linux distro? It's pretty quick to get the right version for Windows. As far as Linux, I would expect to see mainly the big couple Linux distros. The more esoteric rolling releases should obviously be fine due to their rolling nature. Therefore, I want to just do an analysis. As far as supported Ubuntu releases go, 18.04LTS and all supported non-LTS are fine. Ubuntu 16.04 and 14.04 are both LTS version and still supported by Canonical. I believe Mint still follows Ubuntu. As far as Debian, testing and unstable have 3.7, but stable has 3.5.3. As far as Fedora, Version 26 and above have python 3.6 or newer. I believe we've discussed RHEL/CentOS, but it appears that anything before 8 doesn't have Python 3 at all, and the CentOS7 SCL has Python 3.6 in it. I don't know which other Linux distros are still generally relevant. I don't know the OSX world, but I assume you can get a binary installer that's no harder than any other Python version.

--
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/2c23caa4-b83a-4e45-9811-a62af2b4c311%40googlegroups.com.

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

--

Joe Tennies
ten...@gmail.com

[Alex Krupp]

The biggest issues with beginners I see at events like Django Girls or just regular Python meetups involve people needing to edit their .bash_profile or .bashrc files. Most people can figure out how to download the right version of Python for their platform, but then their shell to actually use that version of Python is where things go sideways. Same thing with setting the DJANGO_SETTINGS_MODULE.

The basic issues are:

- Figuring out which version of python3 your interpreter is using (and even knowing you need to know that)

- Knowing how to open the appropriate shell settings file, add the right line in the right place, and save it. (Especially since if there is already stuff there, beginners aren't going to have any idea what any of it is doing which only adds to the confusion.)

- Knowing they need to open a new terminal window or source the settings file.

- Knowing how to read the error message if something went wrong, and the fix whatever the problem is.

- Knowing how to actually install Django... E.g. pip vs pip3, to sudo or not to sudo, etc. 

- Knowing what version of Django to install. E.g. beginners mostly aren't going to know what LTS stands for or understand the implications of that.

For beginners, just getting to the point where running the development server doesn't throw an error is probably harder than the rest of the tutorial combined. So I think making it as easy as possible for beginners is a real issue that should be prioritized. As an anecdote, the only reason why Reddit is built on Postgres instead of MySQL is that they couldn't figure out how to get MySQL installed and running.

That being said, my understanding is that there are a bunch of API changes to Python's async modules between Python 3.5 and 3.6, and I know having async functionality in Django is a big deal for a lot of people. If there's money to pay people to work on that full time then it doesn't matter as much, but if there isn't then I'm assuming a lot of that work will probably get pushed back a year to when it'll at least be less work, which is potentially problematic if it's already going to be a multiyear project as is.

While async itself doesn't especially impact me at this point, obviously everyone benefits from having smart people in the larger Python/Django community to create and maintain the packages we all depend on, and I worry about losing folks to node or golang.

I'm not a core developer or otherwise especially active so I could be just misreading to the situation here, but as a casual observer this seems like a bigger risk... Even if getting Django up and running properly is a real pain point for beginners, which it is, it's at least getting easier every year because there are more people and places (both IRL and online) to ask for help. Whereas we've seen a lot of posts recently both on this list and from other folks in the Python community about burn out, and so at least for me doing what we can to ameliorate this by reducing the time it takes to add new features and maintain existing ones is what I would personally prioritize over 3.5 support.

Anyway sorry for bikeshedding into this, just wanted to bring up a couple points that weren't mentioned previously.

[Joe Tennies]

Comments inlined:

On Sat, Jan 26, 2019 at 7:51 PM Alex Krupp <alex....@gmail.com> wrote:

The biggest issues with beginners I see at events like Django Girls or just regular Python meetups involve people needing to edit their .bash_profile or .bashrc files. Most people can figure out how to download the right version of Python for their platform, but then their shell to actually use that version of Python is where things go sideways. Same thing with setting the DJANGO_SETTINGS_MODULE.

Interesting. I mean, I'm a fairly seasoned Linux guy, so I know exactly what you're talking about for the bash configs, but I actually don't think I've ever edited them for Django. I tend to use virtualenv, then venv, now I'm trying to remember to use pyenv instead of just doing it manually.

 

The basic issues are:

- Figuring out which version of python3 your interpreter is using (and even knowing you need to know that)

In a small group tutorial, I'd expect that to be part of your training. That stated, I can see that

 

- Knowing how to open the appropriate shell settings file, add the right line in the right place, and save it. (Especially since if there is already stuff there, beginners aren't going to have any idea what any of it is doing which only adds to the confusion.)

Interesting. I still have the opposite issue that there's whole sets of overridable settings that are just imported on your behalf that I don't know I can override.

 

- Knowing they need to open a new terminal window or source the settings file.

- Knowing how to read the error message if something went wrong, and the fix whatever the problem is.

To some extent, this is the problem with every new framework of any sort you pick up. The only way to get better is through just doing it a lot. It's a bit harsh and shouldn't be interpreted as "We shouldn't make them better" (because we should always make them better), but I think at some point the best way to learn is to fail and flail for a bit.

I do training for my company on Python. Now, they are all professional programmers of some level or another, but I give just enough information for someone to hang themselves on purpose. Now that's better in a scenario where there's people there to help you get up to speed (not just the Django tutorial), but we got quite a few people that complained that I let them do the wrong thing for 5 minutes to learn... until the end where they thanked me because they got a much better understanding in the end.

 

- Knowing how to actually install Django... E.g. pip vs pip3, to sudo or not to sudo, etc. 

I learned pre-pip, so I get it... but I'm a greybeard now, so I think Django is the gateway drug to the Python world in general. One thing I'd like to see in general is Django (or probably a group of Django users) get more opinionated. The only thing I think I've ever heard was South being the best choice and a general leaning towards Postgres. I had done a fair amount of work on Drupal back in the day, and that was the big thing Lullabot brought to the table in that community.

 

- Knowing what version of Django to install. E.g. beginners mostly aren't going to know what LTS stands for or understand the implications of that.

This is why I think the LTS needs to be the prominent version on the webpage and have a blurb about why one SHOULD choose LTS or not.

 

For beginners, just getting to the point where running the development server doesn't throw an error is probably harder than the rest of the tutorial combined. So I think making it as easy as possible for beginners is a real issue that should be prioritized. As an anecdote, the only reason why Reddit is built on Postgres instead of MySQL is that they couldn't figure out how to get MySQL installed and running.

That being said, my understanding is that there are a bunch of API changes to Python's async modules between Python 3.5 and 3.6, and I know having async functionality in Django is a big deal for a lot of people. If there's money to pay people to work on that full time then it doesn't matter as much, but if there isn't then I'm assuming a lot of that work will probably get pushed back a year to when it'll at least be less work, which is potentially problematic if it's already going to be a multiyear project as is.

While async itself doesn't especially impact me at this point, obviously everyone benefits from having smart people in the larger Python/Django community to create and maintain the packages we all depend on, and I worry about losing folks to node or golang.

I mean that is generally outside this conversation as I don't believe there's a chance of making it in for the 3.0 LTS release.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/c948baf5-91a2-4577-aeaa-89735bb2e444%40googlegroups.com.

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

--

Joe Tennies
ten...@gmail.com

[Carlton Gibson]

OK, one last email, then I'm going to bow out of this one... 🙂

I think there are two issues here: 

* Which versions of Python should we support? 

* Which version should we guide beginners to? 

The second of these only depends on the first because we don't support all current versions of Python in the current stable release, but only in the LTS. 

There was a talk at DjangoCon US. I think on f-strings but I can't quite remember, and I couldn't find the video quickly. The point is that it began by asking "Who's on v3.6 or higher?"

It was about a quarter or a maybe a third of the room. That's it. The rest were on Python 3.5 (or lower). And I put it to you that we should consider the audience of "people going to DjangoCon" as likely ahead of the user base in general. (That's a priori but credible I think.) 

So by dropping Python 3.5 we're forcing these folks onto the LTS. 

I think that's sad. 

Django is a mature framework. That often gets talked about as if that makes it boring. But IMO it's quite the contrary. It makes it exciting. It means that for the vast majority of cases there is no need to be on the LTS. You can safely use the latest version, knowing that breaking changes will be few and easily manageable. You can have the bug fixes. You can have the new features. And the cost of that is just a day every nine-months updating. Grab a coffee, read the release notes and spend the rest of the day updating. Likely you're done by lunchtime. (If you're sensibly with your choices of third-party packages this is...) 

People upgrade their third-parties first, Django second, and Python last of all. (I'm always amazed by this on DRF. "I'm using EOL Django but NEED the latest DRF". This happens every time we drop a Django version.) 

If people are on Python 3.5 they'll stick on the LTS if that's the only version that's compatible. 

So we basically create a ghetto. When we could instead have a situation where being on the latest version was just the done thing. 

I don't think we should highlight the LTS version. I don't think we should point the docs to it by default. I don't think we should recommend that that's where users begin. 

I think we should build an environment where everyone™ is using the latest version, and is all the happier for it. 

So, again, for another (related) reason, I think we do wrong by not following Python's supported versions. 

(People are going to need to speak up if they agree with this though, because otherwise it won't change.) (Which is fine too: mine is just one voice.) 

So to the second topic: more or less asyncio. 

The big changes here were 3.4 to 3.5. Channels already works fine on Python 3.5. Python 3.6 introduces async generators, which sure are nice to have, but are not a deal breaker. 

Supporting Python 3.5 through to end of Django 3.0 is not going to make the difference to whether we can add an async view layer (or whether we being) to Django before December 2019 (when we'd drop Python 3.5). 

If there were a serious blocker, I'd be happy to see us being pragmatic about it. "Supporting Python version X means we can't implement important advance Y, so we're dropping that ahead of schedule." Cool. But that's really not the case here. Continuing Python 3.5 support costs us very little against the benefits to Django as a whole. 

Anyway, I'm spoke out here. 🙂

Have a good day all. 

Kind Regards,

Carlton

[Ivan Anishchuk]

Yep, I'm definitely in favor of dropping 3.5 early and using all the nice features extensively. Especially type annotations. All projects I work on use 3.6 or later for quite some time now, whatever debian guys might feel about stability.

Ivan.

--

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/a8e5bc63-15b1-4c77-92ae-59e61daa30fd%40googlegroups.com.

[Tim Allen]

I'm in the camp of having a flexible policy that allows us to have discussions that examine the current state of the Django and Python ecosystems. This allows us to make informed decisions.

As several folks have mentioned before, 3.6 was a more momentous release than most versions of Python. Since moving to it, features that I didn't think I'd like initially have grown into ones I couldn't imagine working without, such as f-strings. Easier to read, less cognitive load of "fill in the blank" replacement, more beautiful code, straightforward to explain newcomers, and faster?! That's just one example of a huge win that might lower the bar to entry of contribution to Django. More efficient memory use in dicts and type annotations are other big wins.

I typically might lean to the side of supporting versions for longer, but in this case, I'm firmly in the 3.6 camp because of the nature of the release.

I also thought I'd mention that within my organization, the version of Python that Django supports is a driver that I appreciate. While some groups keep up with the latest Python versions, other groups aren't as good, only upgrading when necessary. I won't get into the politics of the developers who want newer versions versus sysadmins who don't want to change, but I've appreciated Django helping move things forward.