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 

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 

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,


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+unsubscr...@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 
For more options, visit https://groups.google.com/d/optout.
          • ... Tom Forbes
          • ... Dan Davis
          • ... Florian Apolloner
          • ... Tim Graham
          • ... Joe Tennies
          • ... Tim Graham
          • ... Carlton Gibson
          • ... Joe Tennies
          • ... Alex Krupp
          • ... Joe Tennies
          • ... Carlton Gibson
  • R... Joe Tennies
  • R... 'Ivan Anishchuk' via Django developers (Contributions to Django itself)
    • ... Tim Allen

Reply via email to