Re: Django 2.0 Python version support (Python 3.6+ only?)

[Tim Graham]

I'm okay with keeping Python 3.5 support around. I agree it would be a bit 
impractical to release Django 2.0 in December without being able to run it 
on the most recent Ubuntu LTS.

If we dropped Python 3.5 support after Django 2.1 that would give Django 
(2.1) support until December 2019 (or April 2020 if you had stuck with 1.11 
LTS). Hopefully most Ubuntu LTS users would be migrated to 18.04 by then 
and whatever Python is included there. I guess we'll evaluate it then.

Thanks for the feedback!

On Tuesday, December 27, 2016 at 5:33:35 PM UTC-5, Michael Manfre wrote:
>
>
>
> On Tue, Dec 27, 2016 at 3:52 PM Tim Graham  > wrote:
>
>> Collin raised a fair point in #django-dev that Ubuntu 16.04 bundles 
>> Python 3.5. I guess 16.10 will include Python 3.6 -- that will be released 
>> before Django 2.0 in December 2017.
>>
>> Presumably any Python's we don't drop for 2.0 we will have to support 
>> until the next LTS (which means 2 more years where we can't use any Python 
>> 3.6+ features without extra work to support them on 3.4, 3.5), or else we 
>> risk stranding Django users on some Django version like 2.0 or 2.1 where 
>> they could have received security updates for longer if they stayed on on 
>> 1.11 LTS. I don't like that situation.
>>
>> How would you revise our Python support policy?
>>
>
> I don't think Django should support versions of Python longer than Python 
> is willing to support them. If this means dropping support for a version of 
> Python in a non-LTS, then we should do that. As long as it is sufficiently 
> documented, users will be able to make an informed decision about whether 
> to stay on the previous LTS for longer Python version support, or move on 
> to our non-LTS releases to reap the rewards of the newer Django version. 
> Regardless what they choose, when they end up on the next LTS, they would 
> have likely updated Django and Python independently along the way.
>  
>
>> In my mind, the purpose of LTS is for conservative organizations that 
>> don't want to use the latest Python, Django, etc. Are Red Hat users on 
>> Python 3.4 demanding the latest Django? Maybe if Django is more aggressive 
>> about dropping old Pythons, those users will demand newer Pythons.
>>
>
> At the organizations I've worked at, the purpose of LTS was to allow them 
> to defer migrating versions for a few years, and not to avoid using the 
> latest version now. They would jump on to an LTS release immediately if it 
> lined up with their planning.
>
> If Red Hat users will be stuck on 3.4, then I feel the burden for 
> supporting it (backporting security fixes) should fall on Red Hat, not 
> Django. We should make it as easy as possible for them to do so (e.g. 
> pre-notification), but not by adding more support burden (conditional code, 
> build matricies, etc.) to Django or preventing us from using newer features 
> from Python.
>
> Regards,
> Michael Manfre
>

-- 
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/d9484416-1aa0-406c-a9c8-f8153b350482%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 2.0 Python version support (Python 3.6+ only?)

[Michael Manfre]

On Tue, Dec 27, 2016 at 3:52 PM Tim Graham  wrote:

> Collin raised a fair point in #django-dev that Ubuntu 16.04 bundles Python
> 3.5. I guess 16.10 will include Python 3.6 -- that will be released before
> Django 2.0 in December 2017.
>
> Presumably any Python's we don't drop for 2.0 we will have to support
> until the next LTS (which means 2 more years where we can't use any Python
> 3.6+ features without extra work to support them on 3.4, 3.5), or else we
> risk stranding Django users on some Django version like 2.0 or 2.1 where
> they could have received security updates for longer if they stayed on on
> 1.11 LTS. I don't like that situation.
>
> How would you revise our Python support policy?
>

I don't think Django should support versions of Python longer than Python
is willing to support them. If this means dropping support for a version of
Python in a non-LTS, then we should do that. As long as it is sufficiently
documented, users will be able to make an informed decision about whether
to stay on the previous LTS for longer Python version support, or move on
to our non-LTS releases to reap the rewards of the newer Django version.
Regardless what they choose, when they end up on the next LTS, they would
have likely updated Django and Python independently along the way.


> In my mind, the purpose of LTS is for conservative organizations that
> don't want to use the latest Python, Django, etc. Are Red Hat users on
> Python 3.4 demanding the latest Django? Maybe if Django is more aggressive
> about dropping old Pythons, those users will demand newer Pythons.
>

At the organizations I've worked at, the purpose of LTS was to allow them
to defer migrating versions for a few years, and not to avoid using the
latest version now. They would jump on to an LTS release immediately if it
lined up with their planning.

If Red Hat users will be stuck on 3.4, then I feel the burden for
supporting it (backporting security fixes) should fall on Red Hat, not
Django. We should make it as easy as possible for them to do so (e.g.
pre-notification), but not by adding more support burden (conditional code,
build matricies, etc.) to Django or preventing us from using newer features
from Python.

Regards,
Michael Manfre

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

Re: Django 2.0 Python version support (Python 3.6+ only?)

[Tim Graham]

Yes, Django 1.11 is the last version to support Python 2.7. This is 
documented in the 1.11 release notes, in 
https://www.djangoproject.com/download/#supported-versions, and elsewhere. 

On Tuesday, December 27, 2016 at 4:37:06 PM UTC-5, MMeent wrote:
>
> I won't mind dropping support for Python versions that are not supported 
> up to the end of the support period of the next LTS (2.2 in this case). If 
> you want to use long-term stability and/or support for current Python 
> versions, you should use the current django LTS version, which will be 
> 1.11. I am perfectly fine with django dropping support for a python version 
> that won't be supported for over 1 1/2 years of that (major) versions 
> support cycle.
>
> Noting that python 2.x also has an EOL in 2020, this one being half a year 
> earlier (March 16th vs September 13th), will django 2.0 drop python 2.7 
> support, or will the 2.x series continue support for 2.7? I cant really 
> find definite docs on that. 
> (https://www.djangoproject.com/weblog/2015/jun/25/roadmap/ talks about it 
> but is not completely clear)
>
> If django drops 2.7 for django 2.x, a lot of code will probably be 
> reworked, and seeing the 3.6 features I would love to see those available 
> directly while removing/refactoring the compat-layer. e.g. f-strings 
> instead of "{}".format or %-formatting, as it is less prone to random 
> bugs like https://code.djangoproject.com/ticket/6343 .
>
>
> -Matthias
>
> On 27 Dec 2016 21:25, "Florian Apolloner"  > wrote:
>
>> Imo we should not drop Python versions overeagerly. After all I do not 
>> wanna compile our own python for djangoproject.com :D Given that Redhat 
>> is on Python 3.4 for the foreseeable future, I'd actually even like to see 
>> 3.4 still supported in Django 2.0 unless there is a good reason to drop it. 
>> Fwiw, Ubuntu Trusty which is LTS and still supported also is on Python 3.4. 
>> So unless there are compelling arguments to drop 3.4, lets keep it as long 
>> as it is not too much work.
>>
>> Either way, I am completely against dropping Python 3.5 now -- lets make 
>> the Django 2.0 migration not more painful than it has to be (ie I do not 
>> want to force people to upgrade existing supported systems just to get the 
>> latest python and therefor Django).
>>
>> Cheers,
>> Florian
>>
>> On Tuesday, December 27, 2016 at 4:12:57 PM UTC+1, Tim Graham wrote:
>>>
>>> When I drafted the 1.11 release notes in May, I wrote, "The next major 
>>> release, Django 2.0, will only support Python 3.5+."
>>>
>>> Our Python version support policy is "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."
>>>
>>> Python 3.5's EOL is September 2020 which I think is sufficiently close 
>>> to Django 1.11's EOL of April 2020 that we could say Django 2.0 is Python 
>>> 3.6+. The alternative is not to drop Python 3.5 compatibility until Django 
>>> 2.2 LTS which is supported until April 2022. I don't see much advantage to 
>>> that. Any objections?
>>>
>>> p.s. There is already a ticket suggesting to take advantage of a Python 
>>> 3.6 feature:
>>> https://code.djangoproject.com/ticket/27635* - *django.utils.crypto 
>>> should use secrets on Python 3.6+
>>>
>> -- 
>> 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/f1da2b09-0309-46e6-9a7c-75ea9cd6f91b%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/ac2f74ea-3a4e-42e0-9a50-3b1df3fbb45c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 2.0 Python version support (Python 3.6+ only?)

[Matthias welp]

I won't mind dropping support for Python versions that are not supported up
to the end of the support period of the next LTS (2.2 in this case). If you
want to use long-term stability and/or support for current Python versions,
you should use the current django LTS version, which will be 1.11. I am
perfectly fine with django dropping support for a python version that won't
be supported for over 1 1/2 years of that (major) versions support cycle.

Noting that python 2.x also has an EOL in 2020, this one being half a year
earlier (March 16th vs September 13th), will django 2.0 drop python 2.7
support, or will the 2.x series continue support for 2.7? I cant really
find definite docs on that.
(https://www.djangoproject.com/weblog/2015/jun/25/roadmap/ talks about it
but is not completely clear)

If django drops 2.7 for django 2.x, a lot of code will probably be
reworked, and seeing the 3.6 features I would love to see those available
directly while removing/refactoring the compat-layer. e.g. f-strings
instead of "{}".format or %-formatting, as it is less prone to random bugs
like https://code.djangoproject.com/ticket/6343 .


-Matthias

On 27 Dec 2016 21:25, "Florian Apolloner"  wrote:

> Imo we should not drop Python versions overeagerly. After all I do not
> wanna compile our own python for djangoproject.com :D Given that Redhat
> is on Python 3.4 for the foreseeable future, I'd actually even like to see
> 3.4 still supported in Django 2.0 unless there is a good reason to drop it.
> Fwiw, Ubuntu Trusty which is LTS and still supported also is on Python 3.4.
> So unless there are compelling arguments to drop 3.4, lets keep it as long
> as it is not too much work.
>
> Either way, I am completely against dropping Python 3.5 now -- lets make
> the Django 2.0 migration not more painful than it has to be (ie I do not
> want to force people to upgrade existing supported systems just to get the
> latest python and therefor Django).
>
> Cheers,
> Florian
>
> On Tuesday, December 27, 2016 at 4:12:57 PM UTC+1, Tim Graham wrote:
>>
>> When I drafted the 1.11 release notes in May, I wrote, "The next major
>> release, Django 2.0, will only support Python 3.5+."
>>
>> Our Python version support policy is "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."
>>
>> Python 3.5's EOL is September 2020 which I think is sufficiently close to
>> Django 1.11's EOL of April 2020 that we could say Django 2.0 is Python
>> 3.6+. The alternative is not to drop Python 3.5 compatibility until Django
>> 2.2 LTS which is supported until April 2022. I don't see much advantage to
>> that. Any objections?
>>
>> p.s. There is already a ticket suggesting to take advantage of a Python
>> 3.6 feature:
>> https://code.djangoproject.com/ticket/27635* - *django.utils.crypto
>> should use secrets on Python 3.6+
>>
> --
> 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/f1da2b09-0309-46e6-9a7c-
> 75ea9cd6f91b%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/CAEze2Wi7TWyvfaS9bkDaN1vwXv%2BnfJBpz0cjVxexbw7t-G1rAg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding custom attributes to Django sitemaps framework

[Tim Graham]

I don't have a lot of experience with sitemaps so at least for me, it would 
be nice to see some proposed code changes to understand the idea a bit 
better. From my naive point of view, it looks like you need  a custom 
template to output  anyway?

On Tuesday, December 27, 2016 at 2:37:20 PM UTC-5, Akshay Raj Gollahalli 
wrote:
>
> Hi,
>
> I am not sure if this has been discussed before or not. I think adding a 
> custom attribute to sitemap template would a nice thing to do. 
>
> As of now the 
> https://github.com/django/django/tree/stable/1.10.x/django/contrib/sitemaps/templates
>  template 
> has 
> http://www.sitemaps.org/schemas/sitemap/0.9";>
>
> Only that, but if I want to add *xmlns:image* I have to create a custom 
> sitemap template. Rather than doing that, something like 
> https://docs.djangoproject.com/en/1.10/ref/contrib/syndication/#custom-feed-generators
>  by 
> defining custom attributes.
>
>

-- 
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/30b3d608-161a-4172-9863-78f93bc4df04%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 2.0 Python version support (Python 3.6+ only?)

[Tim Graham]

Collin raised a fair point in #django-dev that Ubuntu 16.04 bundles Python 
3.5. I guess 16.10 will include Python 3.6 -- that will be released before 
Django 2.0 in December 2017.

Presumably any Python's we don't drop for 2.0 we will have to support until 
the next LTS (which means 2 more years where we can't use any Python 3.6+ 
features without extra work to support them on 3.4, 3.5), or else we risk 
stranding Django users on some Django version like 2.0 or 2.1 where they 
could have received security updates for longer if they stayed on on 1.11 
LTS. I don't like that situation.

How would you revise our Python support policy?

In my mind, the purpose of LTS is for conservative organizations that don't 
want to use the latest Python, Django, etc. Are Red Hat users on Python 3.4 
demanding the latest Django? Maybe if Django is more aggressive about 
dropping old Pythons, those users will demand newer Pythons.

It's hard to quantify how much extra work it is to support old Python 
versions, but besides the overhead of conditional code, dropping old 
versions also brings the possibility to use new features in Python. It also 
increases the size of build matrices across the entire Django ecosystem 
since most packages follow Django's version support.

https://www.djangoproject.com/download/#supported-versions
https://docs.python.org/devguide/#status-of-python-branches

On Tuesday, December 27, 2016 at 3:25:39 PM UTC-5, Florian Apolloner wrote:
>
> Imo we should not drop Python versions overeagerly. After all I do not 
> wanna compile our own python for djangoproject.com :D Given that Redhat 
> is on Python 3.4 for the foreseeable future, I'd actually even like to see 
> 3.4 still supported in Django 2.0 unless there is a good reason to drop it. 
> Fwiw, Ubuntu Trusty which is LTS and still supported also is on Python 3.4. 
> So unless there are compelling arguments to drop 3.4, lets keep it as long 
> as it is not too much work.
>
> Either way, I am completely against dropping Python 3.5 now -- lets make 
> the Django 2.0 migration not more painful than it has to be (ie I do not 
> want to force people to upgrade existing supported systems just to get the 
> latest python and therefor Django).
>
> Cheers,
> Florian
>
> On Tuesday, December 27, 2016 at 4:12:57 PM UTC+1, Tim Graham wrote:
>>
>> When I drafted the 1.11 release notes in May, I wrote, "The next major 
>> release, Django 2.0, will only support Python 3.5+."
>>
>> Our Python version support policy is "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."
>>
>> Python 3.5's EOL is September 2020 which I think is sufficiently close to 
>> Django 1.11's EOL of April 2020 that we could say Django 2.0 is Python 
>> 3.6+. The alternative is not to drop Python 3.5 compatibility until Django 
>> 2.2 LTS which is supported until April 2022. I don't see much advantage to 
>> that. Any objections?
>>
>> p.s. There is already a ticket suggesting to take advantage of a Python 
>> 3.6 feature:
>> https://code.djangoproject.com/ticket/27635* - *django.utils.crypto 
>> should use secrets on Python 3.6+
>>
>

-- 
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/8a4bacd4-8f59-4d84-8ef0-4d7a9d1d5fc4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 2.0 Python version support (Python 3.6+ only?)

[Florian Apolloner]

Imo we should not drop Python versions overeagerly. After all I do not 
wanna compile our own python for djangoproject.com :D Given that Redhat is 
on Python 3.4 for the foreseeable future, I'd actually even like to see 3.4 
still supported in Django 2.0 unless there is a good reason to drop it. 
Fwiw, Ubuntu Trusty which is LTS and still supported also is on Python 3.4. 
So unless there are compelling arguments to drop 3.4, lets keep it as long 
as it is not too much work.

Either way, I am completely against dropping Python 3.5 now -- lets make 
the Django 2.0 migration not more painful than it has to be (ie I do not 
want to force people to upgrade existing supported systems just to get the 
latest python and therefor Django).

Cheers,
Florian

On Tuesday, December 27, 2016 at 4:12:57 PM UTC+1, Tim Graham wrote:
>
> When I drafted the 1.11 release notes in May, I wrote, "The next major 
> release, Django 2.0, will only support Python 3.5+."
>
> Our Python version support policy is "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."
>
> Python 3.5's EOL is September 2020 which I think is sufficiently close to 
> Django 1.11's EOL of April 2020 that we could say Django 2.0 is Python 
> 3.6+. The alternative is not to drop Python 3.5 compatibility until Django 
> 2.2 LTS which is supported until April 2022. I don't see much advantage to 
> that. Any objections?
>
> p.s. There is already a ticket suggesting to take advantage of a Python 
> 3.6 feature:
> https://code.djangoproject.com/ticket/27635* - *django.utils.crypto 
> should use secrets on Python 3.6+
>

-- 
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/f1da2b09-0309-46e6-9a7c-75ea9cd6f91b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Adding custom attributes to Django sitemaps framework

[Akshay Raj Gollahalli]

Hi,

I am not sure if this has been discussed before or not. I think adding a 
custom attribute to sitemap template would a nice thing to do. 

As of now the 
https://github.com/django/django/tree/stable/1.10.x/django/contrib/sitemaps/templates
 template 
has 
http://www.sitemaps.org/schemas/sitemap/0.9";>
Only that, but if I want to add *xmlns:image* I have to create a custom 
sitemap template. Rather than doing that, something like 
https://docs.djangoproject.com/en/1.10/ref/contrib/syndication/#custom-feed-generators
 by 
defining custom attributes.

-- 
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/59314daf-f901-4019-bcd1-b406cb232ebc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Should SECRET_KEY be allowed to be bytes?

[Tim Graham]

Thanks Aymeric. How about this documentation addition:

Uses of the key shouldn't assume that it's text or bytes. Every use should 
go 
through :func:`~django.utils.encoding.force_text` or 
:func:`~django.utils.encoding.force_bytes` to convert it to the desired 
type.

https://github.com/django/django/pull/7750

Adam created https://code.djangoproject.com/ticket/27635 about the "use 
secrets" idea.

On Saturday, December 24, 2016 at 4:52:38 PM UTC-5, Aymeric Augustin wrote:
>
> Hello Andres,
>
> We both seem to agree with the status quo — supporting both text and bytes.
>
>
> On 24 Dec 2016, at 00:36, 'Andres Mejia' via Django developers 
> (Contributions to Django itself)  > wrote:
>
> On 12/22/2016 05:15 PM, Aymeric Augustin wrote:
>
> export SECRET_KEY=… # generated with pwgen -s 50
>
> What do you think is ultimately being used in the pwgen program? I'm going 
> to guess, at least on POSIX systems, it is /dev/urandom or /dev/random, 
> both of which return random bytes.
>
>
> I understand this, but it doesn’t change my argument. I’m saying that the 
> format of SECRET_KEY doesn’t matter, as long as it contain enough entropy, 
> since it will be injected in hashing algorithms designed to extract the 
> entropy. I think we can agree on this.
>
> We have different preferences for that format. You like keeping the 
> original raw binary data SECRET_KEY. I find it more convenient to convert 
> it to an ASCII-safe format, for example with pwgen. I really think this 
> boils down to taste. I don’t think we can conclusively determine that one 
> approach is superior to the other. I think my technique is more beginner 
> friendly; while not applicable to you, it’s a concern for Django in general.
>
> The only cost of supporting both options is that every use must go either 
> through force_text or force_bytes to convert to a known type. 
>
> - “I think it's fair to assume devs using the SECRET_KEY know it must be 
> used as bytes.” — well that doesn't include me or any Django dev I ever 
> talked to about this topic
>
> (..)
>
>
> Oops, I misunderstood “used as bytes” to mean “defined as bytes”. Sorry. I 
> withdraw this.
>
>
> And since I’ve been waving my hands about the types Django expects in a 
> previous email, here’s the full audit. Below, *text* means unicode on 
> Python 2 and str on Python 3. *ASCII-safe bytes* means bytes containing 
> only ASCII-characters, so they can be used transparently as if they were 
> text on Python 2, because it will call decode() implicitly.
>
> - django/conf/global_settings.py
>
> Sets the default to an empty *text* string (note the unicode_literals 
> import at the top for Python 2).
>
> - django/conf/settings.py-tpl
>
> Sets the generated value to *ASCII-safe bytes* on Python 2 and *text* on 
> Python 3 (no unicode_literals there).
>
> - django/core/signing.py:
>
> Calls force_bytes to support *bytes* and *text* in get_cookie_signer.
>
> - django/utils/crypto.py:
>
> Calls force_bytes to support *bytes* and *text* in salted_hmac.
>
> *Assumes SECRET_KEY contains text* in the `if not using_sysrandom` branch 
> of `get_random_string`. This is the bug I hinted to in a previous email. It 
> must have appeared when adding the unicode_literals import to that file. No 
> one complained since June 2012. It only affects people setting their 
> SECRET_KEY to bytes on Python 3 or ASCII-unsafe bytes on Python 2 on 
> Unix-like systems that don’t provide /dev/urandom. This sounds uncommon.
>
> While we’re there, we should use 
> https://docs.python.org/3/library/secrets.html#module-secrets on Python 
> >= 3.6.
>
>
> Best regards,
>
> -- 
> Aymeric.
>
>

-- 
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/50b9dde6-4bab-4f00-b739-df06e90cce3f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Considering removing support for ("iLmsu") regex groups in URLpatterns. Do you use them?

[Tim Graham]

I created a ticket and pull request for the deprecation:

https://code.djangoproject.com/ticket/27648
https://github.com/django/django/pull/7749

On Friday, December 23, 2016 at 10:22:40 AM UTC-5, Tim Graham wrote:
>
> I found a flask thread [0] where Armin Ronacher said this about 
> case-insensitive URLs:
>
> "I think it's a horrible idea. It destroys your caching and creates 
> multiple entries for search engines."
>
> Adam Oakman added: "Agreed. My personal method is to code the 404 handler 
> to look for uppercase characters and redirect to a lowercase equivalent to 
> catch such cases.
>
> I propose to deprecate usage of these regex groups and offer no 
> replacement besides this advice.
>
> [0] 
> http://librelist.com/browser/flask/2011/6/24/case-insensitive-routing/#ea14dfeac18a440b8a792358691f15e0
>
> On Wednesday, December 21, 2016 at 10:21:04 AM UTC-5, Tim Graham wrote:
>>
>> I learned a couple more things:
>> - The end of the Python deprecation is TBA (not in 3.7 as I stated 
>> before), perhaps not until Python 2.7 is unsupported (4 more years).
>> - Using (?i) in urlpatterns is promoted at 
>> http://stackoverflow.com/questions/1515634/case-insensitive-urls-for-django
>>
>> If case-insensitive URL matching is going to before a more formal 
>> feature, maybe it makes sense to either 1) have a global "setting" that 
>> makes all patterns case-insensitive or 2) restrict the case-insensitive 
>> designation to urlpatterns in the ROOT_URLCONF (to avoid the ambiguous 
>> nesting problem that Marten mentioned).
>>
>> Alternatively, we could decide that it's not Django's job to provide this 
>> (not sure if other frameworks do -- personally I don't see case-insensitive 
>> URLs as a best practice) and instead suggest configuring your front-end 
>> webserver (e.g. Apache mod_rewrite) to handle it such as by converting URLs 
>> to lowercase before passing them to Django. A Django middleware might also 
>> be able to do this, idea from [2].
>>
>> related links:
>> https://groups.google.com/d/topic/django-users/X0MkPp-_R-Q/discussion "I 
>> would like to make urls of my site case-insensitive."
>>
>> http://stackoverflow.com/questions/14814419/how-do-i-make-urls-case-insensitive-in-linux-server
>>  
>> - "How do I make URLs case insensitive in Linux server"
>> [2] 
>> https://groups.google.com/d/topic/django-developers/UehV6WZhJTM/discussion 
>> - Case-insensitive URLS
>>
>> On Tuesday, December 20, 2016 at 1:01:44 PM UTC-5, Marten Kenbeek wrote:
>>>
>>> This issue is actually limited to reverse(). When resolving urls, each 
>>> nested regex is matched against the url separately, so you can just apply 
>>> the flags to the "local" regex pattern, and get:
>>>
>>> a/c/
>>> a/C/
>>> a/b/
>>>
>>> matching, but not:
>>>
>>> A/c/
>>> A/C/
>>> A/b/
>>>
>>> The behaviour for reverse() can be a problem. For example, consider the 
>>> following patterns:
>>>
>>> url(r'([A-Z]+)/', include('b'))
>>>
>>> and in b:
>>>
>>> url(r'([A-Z]+)/$', blah, name='blah', flags=re.I)
>>>
>>> Since the flag can only apply to the combined pattern 
>>> r'([A-Z]+)/([A-Z]+)/$', we can either incorrectly reject reverse('blah', 
>>> args=('A', 'b')), or we can return an invalid url for reverse('blah', 
>>> args=('a', 'b')). 
>>>
>>> This seems to be a problem with the current implementation as well, 
>>> which would return an invalid url for reverse('blah', args=('a', 'b')), 
>>> since (?i) applies to the whole pattern regardless of its position. 
>>>
>>> re.I is probably the only flag we need to care about. re.U is always 
>>> used, use of re.L is discouraged, and re.M/re.S only apply to multi-line 
>>> strings. 
>>>
>>> On Tuesday, December 20, 2016 at 5:50:39 PM UTC+1, Shai Berger wrote:

 I think part of Sjoerd's point was that current implementation also 
 means that 
 including the flag in a child affects parents -- but only with regard 
 to said 
 child. So, if you have 

 url('a/', include("b")) 

 and in b: 

 url('b/$', blah), 
 url('c/$', bleh, flags=re.I), 

 then the valid urls include 

 a/c/ 
 A/c/ 
 a/C/ 
 A/C/ 
 a/b/ 

 but not 

 A/b/ 

 which is a bit odd. 

 On Tuesday 20 December 2016 12:21:18 Adam Johnson wrote: 
 > I think the current implementation means they affect all included 
 children. 
 > 
 > On 20 December 2016 at 07:15, Sjoerd Job Postmus  
 wrote: 
 > > On Mon, Dec 19, 2016 at 08:23:09AM +, Adam Johnson wrote: 
 > > > >  I guess the "safest" option is to keep the code around and let 
 this 
 > > > > 
 > > > > feature die when the deprecation ends in Python 3.7 (and 
 meanwhile 
 > > > > see 
 > > 
 > > if 
 > > 
 > > > > anyone notices the deprecation warning in their code and files 
 a 
 > > > > ticket about it). The only extra work compared to removing this 
 now 
 > > > > is 
 > > 
 > > silencing 

Django 2.0 Python version support (Python 3.6+ only?)

[Tim Graham]

When I drafted the 1.11 release notes in May, I wrote, "The next major 
release, Django 2.0, will only support Python 3.5+."

Our Python version support policy is "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."

Python 3.5's EOL is September 2020 which I think is sufficiently close to 
Django 1.11's EOL of April 2020 that we could say Django 2.0 is Python 
3.6+. The alternative is not to drop Python 3.5 compatibility until Django 
2.2 LTS which is supported until April 2022. I don't see much advantage to 
that. Any objections?

p.s. There is already a ticket suggesting to take advantage of a Python 3.6 
feature:
https://code.djangoproject.com/ticket/27635* - *django.utils.crypto should 
use secrets on Python 3.6+

-- 
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/1ed824c7-4775-4951-a00c-5223ac431cf5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: No 'Content-Type' header in response

[Tim Graham]

Don't worry about the unrelated failures, hopefully we'll get that other PR 
merged soon.

On Tuesday, December 27, 2016 at 12:01:36 AM UTC-5, roboslone wrote:
>
> Okay, so I've submitted a pull-request 
>  resolving this issue. But 
> tests for timesince, timeuntil are still broken. I believe #27637 
>  (PR 
> ) fixes them.
> Do I need to do anything to fix those tests in my PR? Merging felixmm's PR 
> in my fork doesn't seem right.
>
> On 27 Dec 2016, at 06:36, roboslone > 
> wrote:
>
> Oh, nevermind. Instructions are attached to the ticket. I'll start to work 
> on this.
>
> On 27 Dec 2016, at 06:33, roboslone > 
> wrote:
>
> So how can I help resolve this? Should I just fork Django on GitHub and 
> make a pull-request?
>
> On 26 Dec 2016, at 15:45, Curtis Maloney  > wrote:
>
> From what I can see in the rfc, it is permitted but not required.
>
> Only a body in a 204 response is proscribed.
>
> Any metadata (I.e. headers) are about the resource just accessed... So a 
> Content-Type would, IMHO, be acceptable but not essential.
>
>
>
> On 26 December 2016 9:47:02 PM AEDT, roboslone  > wrote:
>>
>> Thanks, that was an old setting in Mail.app =/
>>
>> I've made a pull-request to DRF: 
>> https://github.com/tomchristie/django-rest-framework/pull/4768
>> But it seems to me that fixing it in Django would be more appropriate.
>>
>> On the subject of Content-Type header with no response body, seems 
>> there's no convention about it, I've found different opinions on the web. 
>> The only thing I'm sure about is that putting None in that header is a bad 
>> idea.
>>
>> On 26 Dec 2016, at 13:24, Adam Johnson > 
>> wrote:
>>
>> Hi GMail! (you might want to fix your name used on google groups, I had 
>> the same problem ;) )
>>
>> This seems to be a legitimate bug in the __repr__ to me - SO informs me 
>> that DRF is correct in not defining a Content-Type for a 204 as it has no 
>> body: 
>> https://stackoverflow.com/questions/21029351/what-content-type-should-a-204-no-response-use
>>
>> I created a ticket: https://code.djangoproject.com/ticket/27640 . If you 
>> want to try fix it there's a great contribution guide at 
>> https://docs.djangoproject.com/en/dev/internals/contributing/ . I think 
>> using str.format would be acceptable, but the dict subclass sounds more 
>> complicated than just doing self.get('Content-Type', '') :)
>>
>> On 26 December 2016 at 05:57, GMail > 
>> wrote:
>>
>>> Hi! I'm using Django 1.10.2 and Django-Rest-Framework 3.5.3.
>>> I noticed, that HttpRequest.__repr__ method relies on 'Content-Type' 
>>> header:
>>>
>>>
>>> > class HttpResponse(HttpResponseBase):
>>> > ...
>>> >
>>> > def __repr__(self):
>>> > return '<%(cls)s status_code=%(status_code)d, 
>>> "%(content_type)s">' % {
>>> > 'cls': self.__class__.__name__,
>>> > 'status_code': self.status_code,
>>> > 'content_type': self['Content-Type'],
>>> > }
>>>
>>>
>>> And after deleting an object in DRF sends empty response with HTTP204 
>>> and no 'Content-Type' header. I was trying to log outgoing response and got 
>>> KeyError here.
>>>
>>> So I have two questions:
>>> 1. Is this intentional? Do all responses in Django have 'Content-Type' 
>>> header and should DRF be aware of it?
>>> 2. Why not use `str.format` here? To avoid errors like this, `dict` 
>>> subclass with `__missing__` method could be used.
>>>
>>> --
>>> 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/39F85D40-019C-411A-BCA7-402E338EA527%40gmail.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-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/CAMyDDM39qZj7fV-MvPX%2BtXvSNL9%2B80283Aa5P47uBh3D46Q8BQ%40mail.gmail.com
>>  
>> 
>> .
>> For