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.smea...@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 tenn...@gmail.com -- 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 https://groups.google.com/d/msgid/django-developers/CACiOJ6szy2GKbNF9QuyzYHyitqQhhGk3eF%2BTyju00rNCEjOZ1w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
