Re: revisiting the Python version support policy

[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

-- 
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/85adb894-c908-4835-98fe-96c859d79a15%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: revisiting the Python version support policy

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

On Tue, 22 Jan 2019 at 10:07, Claude Paroz  wrote:

> 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
>
> --
> 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/85adb894-c908-4835-98fe-96c859d79a15%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Adam

-- 
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/CAMyDDM06JVaGXYK9mQt%3DzujOQ6_UuPx7RKjz8jYZORxA_fnE_g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Potential suspension of Channels development

[John Obelenus]

Chiming in. As a long-time django user (nearly a decade), websockets is an 
area that the project on the whole is very, very, far behind the leading 
edge of the web industry. It's great, often desirable, to not be *on* the 
leading edge, but in my opinion, the project is too far behind it.

There are numerous projects where I would, now, not consider using django 
(or at least, using it only for the admin to save time/effort). That is the 
first issue that I see for the django project as a whole.

Secondly, and probably something Andrew expects to be helped (if not 
outright solved), is the general speed of serving requests. Async can 
absolutely help here (How much it helps is up for debate). As a developer 
who is using a lot more NodeJS now the inherent speed in that platform's 
request lifecycle can often be a game-changer in terms of performance and 
resources needed.

On Monday, January 21, 2019 at 2:57:18 PM UTC-5, Andrew Godwin wrote:
>
>
>
> On Mon, Jan 21, 2019 at 4:34 AM Michael Martinez  > wrote:
>
>> Hi Andrew
>>
>> To me, Websockets is the defining use case for using Django Channels. 
>> From a user POV, saying that Channels is focused on the wrong problem 
>> (websockets) is like saying Django is too focused on HTTP.
>>
>> When I have selected Channels (vs other tools), my rationale was not:
>>
>> "*I need a general purpose async platform and it would be great if it 
>> worked with Websockets, ZeromQ and played nice with Django...*" 
>> (therefore Django Channels vs Tornado vs ...)
>>
>>
>> rather my rationale is more like: 
>>
>> "*I need to build real time features with Websockets using Django..*" 
>> (therefore Django Channels).
>>
>>  
>>
>
> Oh, I totally get that, and Channels does well at providing WebSockets - 
> the problem is that it's still an area with a lot less interest and also 
> one I personally have no use for at the moment. Those things combined mean 
> that WebSockets is not something I'm really interested in supporting for 
> free right now; I'd have to be paid to work on it (as I was with the 
> Mozilla grant for a lot of Channels' development).
>
> Andrew 
>

-- 
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/b357add7-cd44-4c12-b29b-0d28150417a2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: revisiting the Python version support policy

[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 


On Monday, January 21, 2019 at 10:56:40 AM UTC-5, Tim Graham wrote:
>
> 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
>

-- 
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/51dfc517-8b5a-4803-9f8d-daa1bf920e7b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: revisiting the Python version support policy

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


On Tue, Jan 22, 2019 at 10:04 AM Federico Capoano <
federico.capo...@gmail.com> wrote:

> 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
>
>
> On Monday, January 21, 2019 at 10:56:40 AM UTC-5, Tim Graham wrote:
>>
>> 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
>>
> --
> 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/51dfc517-8b5a-4803-9f8d-daa1bf920e7b%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Introduction GSoC

[akki]

Also, if Django does participate in GSoC this year, they'll have an ideas page 
for it eventually similar to something like this - 
https://code.djangoproject.com/wiki/SummerOfCode2018.

The best thing that you can do today to improve your chances is start 
contributing!

-- 
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/6bccbc0f-347c-4a93-9dba-11fe2829da16%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: revisiting the Python version support policy

[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


On Tue, Jan 22, 2019 at 6:11 PM Collin Anderson 
wrote:

> 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.
>
>
> On Tue, Jan 22, 2019 at 10:04 AM Federico Capoano <
> federico.capo...@gmail.com> wrote:
>
>> 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
>>
>>
>> On Monday, January 21, 2019 at 10:56:40 AM UTC-5, Tim Graham wrote:
>>>
>>> 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
>>>
>> --
>> 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/51dfc517-8b5a-4803-9f8d-daa1bf920e7b%40googlegroups.com
>> 

Re: revisiting the Python version support policy

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

On Wednesday, 23 January 2019 02:03:54 UTC+11, Federico Capoano wrote:
>
> 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 
>
>
> On Monday, January 21, 2019 at 10:56:40 AM UTC-5, Tim Graham wrote:
>>
>> 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
>>
>

-- 
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/a8e5bc63-15b1-4c77-92ae-59e61daa30fd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: revisiting the Python version support policy

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

-- 
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/CAL13Cg8Kccb0p0pySci1cWxHYB7RrWFV%3DmX-HwULk%2B3FEVkrgA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: revisiting the Python version support policy

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