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: DEP pre-proposal for a simpler URLs syntax.

[Matthias welp]

Hi,

I may be late, but using 'path' as a name for this function is in my
opinion not recommended. It would shadow the stdlib os.path,
albeit not as a library, but as a function.

Using 'route' would be more interesting in my opinion, but shadowing
the Channels 'route' function (which has a very similar interface, but
different enough to confuse people) makes this also not really doable.

I think changing the behaviour of 'url' based on a boolean flag is nicer
in my opinion, as you'd then still have the resonation between the
'{% url %}' template tag and what you put in your urls.py (and no, I
really don't want to rename my files to paths.py). An alternative to
url with easy flags is, well, just calling it 'easy_url'.

TLDR: don't call it 'path', keep 'url' and add flags or call it  'easy_url'
(which may be an alias for url with true flag for easy mode).

-MMeent

-- 
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/CAEze2WjWox_Yh3adzV-5O6FWyaLMtCH-BMumDKeybsOG9fivmg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.