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

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.smea...@gmail.com>

> 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

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