Re: revisiting the Python version support policy

2019-01-30 Thread Tim Allen
I'm in the camp of having a flexible policy that allows us to have 
discussions that examine the current state of the Django and Python 
ecosystems. This allows us to make informed decisions.

As several folks have mentioned before, 3.6 was a more momentous release 
than most versions of Python. Since moving to it, features that I didn't 
think I'd like initially have grown into ones I couldn't imagine working 
without, such as f-strings. Easier to read, less cognitive load of "fill in 
the blank" replacement, more beautiful code, straightforward to explain 
newcomers, and faster?! That's just one example of a huge win that might 
lower the bar to entry of contribution to Django. More efficient memory use 
in dicts and type annotations are other big wins.

I typically might lean to the side of supporting versions for longer, but 
in this case, I'm firmly in the 3.6 camp because of the nature of the 
release.

I also thought I'd mention that within my organization, the version of 
Python that Django supports is a driver that I appreciate. While some 
groups keep up with the latest Python versions, other groups aren't as 
good, only upgrading when necessary. I won't get into the politics of the 
developers who want newer versions versus sysadmins who don't want to 
change, but I've appreciated Django helping move things forward.

-- 
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/d108f73f-72cc-4180-a26b-95920413adcf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: revisiting the Python version support policy

2019-01-29 Thread 'Ivan Anishchuk' via Django developers (Contributions to Django itself)
Yep, I'm definitely in favor of dropping 3.5 early and using all the nice
features extensively. Especially type annotations. All projects I work on
use 3.6 or later for quite some time now, whatever debian guys might feel
about stability.

Ivan.

On Wed, Jan 23, 2019 at 12: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
> - 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.
>

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

Re: revisiting the Python version support policy

2019-01-27 Thread Carlton Gibson
OK, one last email, then I'm going to bow out of this one... 

I think there are two issues here: 

* Which versions of Python should we support? 
* Which version should we guide beginners to? 

The second of these only depends on the first because we don't support all 
current versions of Python in the current stable release, but only in the 
LTS. 

There was a talk at DjangoCon US. I think on f-strings but I can't quite 
remember, and I couldn't find the video quickly. The point is that it began 
by asking "Who's on v3.6 or higher?"
It was about a quarter or a maybe a third of the room. That's it. The rest 
were on Python 3.5 (or lower). And I put it to you that we should consider 
the audience of "people going to DjangoCon" as likely ahead of the user 
base in general. (That's a priori but credible I think.) 

So by dropping Python 3.5 we're forcing these folks onto the LTS. 

I think that's sad. 

Django is a mature framework. That often gets talked about as if that makes 
it boring. But IMO it's quite the contrary. It makes it exciting. It means 
that for the vast majority of cases there is no need to be on the LTS. You 
can safely use the latest version, knowing that breaking changes will be 
few and easily manageable. You can have the bug fixes. You can have the new 
features. And the cost of that is just a day every nine-months updating. 
Grab a coffee, read the release notes and spend the rest of the day 
updating. Likely you're done by lunchtime. (If you're sensibly with your 
choices of third-party packages this is...) 

People upgrade their third-parties first, Django second, and Python last of 
all. (I'm always amazed by this on DRF. "I'm using EOL Django but NEED the 
latest DRF". This happens every time we drop a Django version.) 

If people are on Python 3.5 they'll stick on the LTS if that's the only 
version that's compatible. 

So we basically create a ghetto. When we could instead have a situation 
where being on the latest version was just the done thing. 

I don't think we should highlight the LTS version. I don't think we should 
point the docs to it by default. I don't think we should recommend that 
that's where users begin. 

I think we should build an environment where everyone™ is using the latest 
version, and is all the happier for it. 

So, again, for another (related) reason, I think we do wrong by not 
following Python's supported versions. 
(People are going to need to speak up if they agree with this though, 
because otherwise it won't change.) (Which is fine too: mine is just one 
voice.) 


So to the second topic: more or less asyncio. 

The big changes here were 3.4 to 3.5. Channels already works fine on Python 
3.5. Python 3.6 introduces async generators, which sure are nice to have, 
but are not a deal breaker. 
Supporting Python 3.5 through to end of Django 3.0 is not going to make the 
difference to whether we can add an async view layer (or whether we being) 
to Django before December 2019 (when we'd drop Python 3.5). 

If there were a serious blocker, I'd be happy to see us being pragmatic 
about it. "Supporting Python version X means we can't implement important 
advance Y, so we're dropping that ahead of schedule." Cool. But that's 
really not the case here. Continuing Python 3.5 support costs us very 
little against the benefits to Django as a whole. 

Anyway, I'm spoke out here. 


Have a good day all. 

Kind Regards,

Carlton

-- 
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/84bcd7b9-b2c5-4ab9-bbcb-7fb42c2308d4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: revisiting the Python version support policy

2019-01-26 Thread Joe Tennies
Comments inlined:

On Sat, Jan 26, 2019 at 7:51 PM Alex Krupp  wrote:

> The biggest issues with beginners I see at events like Django Girls or
> just regular Python meetups involve people needing to edit their
> .bash_profile or .bashrc files. Most people can figure out how to download
> the right version of Python for their platform, but then their shell to
> actually use that version of Python is where things go sideways. Same thing
> with setting the DJANGO_SETTINGS_MODULE.
>

Interesting. I mean, I'm a fairly seasoned Linux guy, so I know exactly
what you're talking about for the bash configs, but I actually don't think
I've ever edited them for Django. I tend to use virtualenv, then venv, now
I'm trying to remember to use pyenv instead of just doing it manually.


>
> The basic issues are:
>
> - Figuring out which version of python3 your interpreter is using (and
> even knowing you need to know that)
>

In a small group tutorial, I'd expect that to be part of your training.
That stated, I can see that


> - Knowing how to open the appropriate shell settings file, add the right
> line in the right place, and save it. (Especially since if there is already
> stuff there, beginners aren't going to have any idea what any of it is
> doing which only adds to the confusion.)
>

Interesting. I still have the opposite issue that there's whole sets of
overridable settings that are just imported on your behalf that I don't
know I can override.


>
> - Knowing they need to open a new terminal window or source the settings
> file.
>
> - Knowing how to read the error message if something went wrong, and the
> fix whatever the problem is.
>

To some extent, this is the problem with every new framework of any sort
you pick up. The only way to get better is through just doing it a lot.
It's a bit harsh and shouldn't be interpreted as "We shouldn't make them
better" (because we should always make them better), but I think at some
point the best way to learn is to fail and flail for a bit.

I do training for my company on Python. Now, they are all professional
programmers of some level or another, but I give just enough information
for someone to hang themselves on purpose. Now that's better in a scenario
where there's people there to help you get up to speed (not just the Django
tutorial), but we got quite a few people that complained that I let them do
the wrong thing for 5 minutes to learn... until the end where they thanked
me because they got a much better understanding in the end.


>
> - Knowing how to actually install Django... E.g. pip vs pip3, to sudo or
> not to sudo, etc.
>

I learned pre-pip, so I get it... but I'm a greybeard now, so I think
Django is the gateway drug to the Python world in general. One thing I'd
like to see in general is Django (or probably a group of Django users) get
more opinionated. The only thing I think I've ever heard was South being
the best choice and a general leaning towards Postgres. I had done a fair
amount of work on Drupal back in the day, and that was the big thing
Lullabot brought to the table in that community.


>
> - Knowing what version of Django to install. E.g. beginners mostly aren't
> going to know what LTS stands for or understand the implications of that.
>

This is why I think the LTS needs to be the prominent version on the
webpage and have a blurb about why one SHOULD choose LTS or not.


>
> For beginners, just getting to the point where running the development
> server doesn't throw an error is probably harder than the rest of the
> tutorial combined. So I think making it as easy as possible for beginners
> is a real issue that should be prioritized. As an anecdote, the only reason
> why Reddit is built on Postgres instead of MySQL is that they couldn't
> figure out how to get MySQL installed and running.
>
> That being said, my understanding is that there are a bunch of API changes
> to Python's async modules between Python 3.5 and 3.6, and I know having
> async functionality in Django is a big deal for a lot of people. If there's
> money to pay people to work on that full time then it doesn't matter as
> much, but if there isn't then I'm assuming a lot of that work will probably
> get pushed back a year to when it'll at least be less work, which is
> potentially problematic if it's already going to be a multiyear project as
> is.
>
> While async itself doesn't especially impact me at this point, obviously
> everyone benefits from having smart people in the larger Python/Django
> community to create and maintain the packages we all depend on, and I worry
> about losing folks to node or golang.
>

I mean that is generally outside this conversation as I don't believe
there's a chance of making it in for the 3.0 LTS release.


>
> I'm not a core developer or otherwise especially active so I could be just
> misreading to the situation here, but as a casual observer this seems like
> a bigger risk... Even if getting Django up and running properly is a real
> 

Re: revisiting the Python version support policy

2019-01-26 Thread Alex Krupp
The biggest issues with beginners I see at events like Django Girls or just 
regular Python meetups involve people needing to edit their .bash_profile 
or .bashrc files. Most people can figure out how to download the right 
version of Python for their platform, but then their shell to actually use 
that version of Python is where things go sideways. Same thing with setting 
the DJANGO_SETTINGS_MODULE.

The basic issues are:

- Figuring out which version of python3 your interpreter is using (and even 
knowing you need to know that)

- Knowing how to open the appropriate shell settings file, add the right 
line in the right place, and save it. (Especially since if there is already 
stuff there, beginners aren't going to have any idea what any of it is 
doing which only adds to the confusion.)

- Knowing they need to open a new terminal window or source the settings 
file.

- Knowing how to read the error message if something went wrong, and the 
fix whatever the problem is.

- Knowing how to actually install Django... E.g. pip vs pip3, to sudo or 
not to sudo, etc. 

- Knowing what version of Django to install. E.g. beginners mostly aren't 
going to know what LTS stands for or understand the implications of that.

For beginners, just getting to the point where running the development 
server doesn't throw an error is probably harder than the rest of the 
tutorial combined. So I think making it as easy as possible for beginners 
is a real issue that should be prioritized. As an anecdote, the only reason 
why Reddit is built on Postgres instead of MySQL is that they couldn't 
figure out how to get MySQL installed and running.

That being said, my understanding is that there are a bunch of API changes 
to Python's async modules between Python 3.5 and 3.6, and I know having 
async functionality in Django is a big deal for a lot of people. If there's 
money to pay people to work on that full time then it doesn't matter as 
much, but if there isn't then I'm assuming a lot of that work will probably 
get pushed back a year to when it'll at least be less work, which is 
potentially problematic if it's already going to be a multiyear project as 
is.

While async itself doesn't especially impact me at this point, obviously 
everyone benefits from having smart people in the larger Python/Django 
community to create and maintain the packages we all depend on, and I worry 
about losing folks to node or golang.

I'm not a core developer or otherwise especially active so I could be just 
misreading to the situation here, but as a casual observer this seems like 
a bigger risk... Even if getting Django up and running properly is a real 
pain point for beginners, which it is, it's at least getting easier every 
year because there are more people and places (both IRL and online) to ask 
for help. Whereas we've seen a lot of posts recently both on this list and 
from other folks in the Python community about burn out, and so at least 
for me doing what we can to ameliorate this by reducing the time it takes 
to add new features and maintain existing ones is what I would personally 
prioritize over 3.5 support.

Anyway sorry for bikeshedding into this, just wanted to bring up a couple 
points that weren't mentioned previously.


On Saturday, January 26, 2019 at 5:15:36 PM UTC-5, Rotund wrote:
>
> Carlton,
>
> I read your response, and I think what you said is very important. I would 
> like to ask you a few questions, if you don't mind. I'm not trying to back 
> you into a corner; I'm trying to understand what you see with your teaching 
> and getting insight from that.
>
> Do you think it makes sense to have beginners working off non-LTS 
> versions? Personally, I think the LTS is the version that beginner's should 
> run. They're "real" projects are likely to take longer, and they aren't 
> going to want to track the latest and greatest. I also think that any 
> non-LTS version of the docs should have a similar heading to the dev 
> version to suggest that beginners likely would benefit from using the 
> latest LTS version.
>
> How many people coming to your trainings are running a stable/enterprise 
> Linux distro? It's pretty quick to get the right version for Windows. As 
> far as Linux, I would expect to see mainly the big couple Linux distros. 
> The more esoteric rolling releases should obviously be fine due to their 
> rolling nature. Therefore, I want to just do an analysis. As far as 
> supported Ubuntu releases go, 18.04LTS and all supported non-LTS are fine. 
> Ubuntu 16.04 and 14.04 are both LTS version and still supported by 
> Canonical. I believe Mint still follows Ubuntu. As far as Debian, testing 
> and unstable have 3.7, but stable has 3.5.3. As far as Fedora, Version 26 
> and above have python 3.6 or newer. I believe we've discussed RHEL/CentOS, 
> but it appears that anything before 8 doesn't have Python 3 at all, and the 
> CentOS7 SCL has Python 3.6 in it. I don't know which other Linux distros 
> are 

Re: revisiting the Python version support policy

2019-01-26 Thread Joe Tennies
Carlton,

I read your response, and I think what you said is very important. I would
like to ask you a few questions, if you don't mind. I'm not trying to back
you into a corner; I'm trying to understand what you see with your teaching
and getting insight from that.

Do you think it makes sense to have beginners working off non-LTS versions?
Personally, I think the LTS is the version that beginner's should run.
They're "real" projects are likely to take longer, and they aren't going to
want to track the latest and greatest. I also think that any non-LTS
version of the docs should have a similar heading to the dev version to
suggest that beginners likely would benefit from using the latest LTS
version.

How many people coming to your trainings are running a stable/enterprise
Linux distro? It's pretty quick to get the right version for Windows. As
far as Linux, I would expect to see mainly the big couple Linux distros.
The more esoteric rolling releases should obviously be fine due to their
rolling nature. Therefore, I want to just do an analysis. As far as
supported Ubuntu releases go, 18.04LTS and all supported non-LTS are fine.
Ubuntu 16.04 and 14.04 are both LTS version and still supported by
Canonical. I believe Mint still follows Ubuntu. As far as Debian, testing
and unstable have 3.7, but stable has 3.5.3. As far as Fedora, Version 26
and above have python 3.6 or newer. I believe we've discussed RHEL/CentOS,
but it appears that anything before 8 doesn't have Python 3 at all, and the
CentOS7 SCL has Python 3.6 in it. I don't know which other Linux distros
are still generally relevant. I don't know the OSX world, but I assume you
can get a binary installer that's no harder than any other Python version.

On Sat, Jan 26, 2019 at 3:10 AM Carlton Gibson 
wrote:

> I worry about us making this kind of decision in the rarified air of the
> developer mailing list. It's a technical question yes, but it affects the
> entire community.
>
> I think, here, we underplay just how hard it is for people out there. IMO
> expecting that people suffering from massive information overload to
> successfully switch docs version is already setting the bar too high.
> People really struggle.
>
> I'll give you one concrete example.
>
> Teaching DjangoGirls in Barcelona, one student—presumably for EXACTLY the
> kind of version mis-match we're talking about here—had her project created
> with a different version of the template than everybody else's. It didn't
> have contrib.staticfiles in INSTALLED_APPS. As such, where everyone else
> was able to deploy, her deployment failed. In the end there were
> instructors from three tables around here laptop trying who-knows-what in
> the shell before it was worked out and resolved. ("Try `collectstatic`
> locally" led to the answer.)
>
> Without those instructors present that student would have been stuck at
> that point, and lost.
>
> I don't have figures, and we never hear from most of these people, but I
> guess this sort of difficulty happens a lot.
> A quick scan of django-users suggests it's all the time.
>
> > ...there's a new test failure after a recent patch due to
> non-deterministic dict ordering in Python 3.5 which demonstrates the sort
> of minor annoyances that take time away from making useful improvements to
> Django.
>
> It's not that I don't hear you hear. I do.
>
> It's just that I think of this as an accessibility issue, and
> accessibility is a feature too.
>
> For me, if the cost of including someone is that we have to use
> OrderedDict for a wee-bit longer, then so be it.
>
> Kind Regards,
>
> Carlton
>
>
> --
> 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/2c23caa4-b83a-4e45-9811-a62af2b4c311%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


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

Re: revisiting the Python version support policy

2019-01-26 Thread Carlton Gibson
I worry about us making this kind of decision in the rarified air of the 
developer mailing list. It's a technical question yes, but it affects the 
entire community. 

I think, here, we underplay just how hard it is for people out there. IMO 
expecting that people suffering from massive information overload to 
successfully switch docs version is already setting the bar too high. 
People really struggle. 

I'll give you one concrete example. 

Teaching DjangoGirls in Barcelona, one student—presumably for EXACTLY the 
kind of version mis-match we're talking about here—had her project created 
with a different version of the template than everybody else's. It didn't 
have contrib.staticfiles in INSTALLED_APPS. As such, where everyone else 
was able to deploy, her deployment failed. In the end there were 
instructors from three tables around here laptop trying who-knows-what in 
the shell before it was worked out and resolved. ("Try `collectstatic` 
locally" led to the answer.) 

Without those instructors present that student would have been stuck at 
that point, and lost. 

I don't have figures, and we never hear from most of these people, but I 
guess this sort of difficulty happens a lot. 
A quick scan of django-users suggests it's all the time. 

> ...there's a new test failure after a recent patch due to 
non-deterministic dict ordering in Python 3.5 which demonstrates the sort 
of minor annoyances that take time away from making useful improvements to 
Django.

It's not that I don't hear you hear. I do. 

It's just that I think of this as an accessibility issue, and accessibility 
is a feature too. 

For me, if the cost of including someone is that we have to use OrderedDict 
for a wee-bit longer, then so be it. 

Kind Regards,

Carlton


-- 
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/2c23caa4-b83a-4e45-9811-a62af2b4c311%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: revisiting the Python version support policy

2019-01-25 Thread Joe Tennies
I just want to recap what I'm hearing.

After listening to the arguments, it doesn't sound like many seasoned
developers/Django users would need the 3.5 support to remain for
development purposes. Therefore, their needs don't seem to need to be
considered.
Larger organizations may have issues with Enterprise/LTS Linux distros not
having that version of Python by default for deploying. This is not a top
concern, but it is at least a slight concern.
Beginning and unseasoned Django users can be easily confused by choices.
This has been the focus of much of this discussion. This seems to be a
pretty major concern. Is there a way that we deal with this? I have some
suggestions below.

I am not sure that that last issue can be as easily solved by technical
solutions as much as social/documentation solutions. Therefore, I'm going
to point out some things that I'm noticing.

First, the main Django webpage only mentions the very latest release. I
think that this should be updated to more prominently show the latest LTS
release. It should also show all currently supported releases underneath it.

Secondly, should we be suggesting that beginners stick to the latest LTS
version? I think this makes sense as there should be better documentation
and people will not have to deal as much with just general churn. This
leads into "how would a beginner get the latest LTS version?" Let's assume
they understand pip. Is there a way for them to get pinned to the latest
Django LTS release? Should Django have a package in pypi named django-lts
that is just a dummy package that has a dependency of django>=1.11.0,<2.0?
Would this break on a pip update that would update all packages? I'm trying
to think of any scenarios where someone could jump off an LTS accidentally
without doing something completely wrong.

Thirdly, if we do push people towards the LTS releases, should
docs.djangoproject.com default to the latest LTS version instead of the
latest release (whether LTS or not)?

Fourthly, I think the documentation should more clearly state what version
of Python it supports. I'm looking at the 2.1 documentation (current thing
a beginner would see), and I don't see it. It's not on the first half of
the main page, nor the install instructions. I do see a suggestion for
"lastest version" (which may not be supported yet if right after a new
Python release -- too new) or "use OS's package manager (which we just
stated would not be new enough if using a more stable distro -- too old).

That ends my thoughts on the unseasoned Django user, but I had a potential
concern that I hadn't heard brought up. Is there any added effort as far as
deploying to a non-system version of Python? I have an odd deployment on
Dreamhost that uses passenger to deploy my Django apps. I have to do a
weird passenger_wsgi.py file as mentioned in
https://help.dreamhost.com/hc/en-us/articles/360002341572-How-to-create-a-Django-2-project-using-virtualenv
that changes the Python interpreter on the fly. Does that affect something
like mod_wsgi, uwsgi, gunicorn, or some other wsgi runner? I mean if it
would come down to recompiling Apache or some such, that would put a fair
amount of burden on someone to deploy. If it stays generally separate then
it's fine.

Assuming the deployment issue is "only in rare/corner cases" or less, I
think the grand majority of the concerns could be fixed through
documentation and website updates.





On Fri, Jan 25, 2019 at 9:04 AM Tim Graham  wrote:

> Can you explain more about what they struggled with? Maybe there's other
> ways to solve those problems.
>
> On Friday, January 25, 2019 at 9:43:37 AM UTC-5, Tom Forbes wrote:
>>
>> This message really resonated with me, especially after helping a few
>> beginners get started with Python and watching them struggle with exactly
>> this kind of thing.
>>
>> I'd be +1 on following Python. Looking through the diff there is not a
>> huge amount of things to remove and IMO none of them are really holding us
>> back or all that serious. We've fixed some issues with mangling cached
>> property names, some workarounds for ModuleNotFoundError/ImportError and an
>> issue with sqlite3 on 3.5.
>>
>> On 24 January 2019 at 20:33:42, Carlton Gibson (carlton...@gmail.com)
>> wrote:
>>
>> To be honest, I'm surprised there's even one person who comes within a
>> 1000 miles of this list who's using Python 3.5. :)
>>
>> My reason for thinking we should follow Python's supported versions is
>> users, and particularly beginning users, who have got they-don't-know
>> version and find a tutorial just what... no sorry need... `pip3 install
>> Django` to work, and give them the version of Django that corresponds to
>> what they see when they visit docs.djangoproject.com.
>>
>> I don't agree this is theoretical at all.
>>
>> It's not just Debian. (Which doesn't fit my mental model here really...)
>>
>> It's all those few-years-old computers out there.
>>
>> It's for example Raspbian, which as of this month is still 

Re: revisiting the Python version support policy

2019-01-25 Thread Florian Apolloner
FWIW, most of my problems with python version dependencies went away when I 
started to use a custom build on our servers. Allows easy upgrades and a 
good environment for our programs.

On Friday, January 25, 2019 at 4:01:28 PM UTC+1, Dan Davis wrote:
>
> My employer is still using CPython 3.4.6 on the servers, and CPython 3.5.1 
> on the desktop.   I've been instrumental in developing a plan to move 
> forward.  I know of one established company and one start-up, by name, 
> where they are still using CPython 2.7 (and a horrendously old version of 
> Django), because it is hard to upgrade.   As long as Django has a LTS 
> version, such as 1.11, and soon 2.2, I think forcing an upgrade is OK.  
>  But it is good to be aware of what's out there.
>
> On Fri, Jan 25, 2019 at 9:43 AM Tom Forbes > 
> wrote:
>
>> This message really resonated with me, especially after helping a few 
>> beginners get started with Python and watching them struggle with exactly 
>> this kind of thing.
>>
>> I'd be +1 on following Python. Looking through the diff there is not a 
>> huge amount of things to remove and IMO none of them are really holding us 
>> back or all that serious. We've fixed some issues with mangling cached 
>> property names, some workarounds for ModuleNotFoundError/ImportError and an 
>> issue with sqlite3 on 3.5.
>>
>> On 24 January 2019 at 20:33:42, Carlton Gibson (carlton...@gmail.com 
>> ) wrote:
>>
>> To be honest, I'm surprised there's even one person who comes within a 
>> 1000 miles of this list who's using Python 3.5. :) 
>>
>> My reason for thinking we should follow Python's supported versions is 
>> users, and particularly beginning users, who have got they-don't-know 
>> version and find a tutorial just what... no sorry need... `pip3 install 
>> Django` to work, and give them the version of Django that corresponds to 
>> what they see when they visit docs.djangoproject.com. 
>>
>> I don't agree this is theoretical at all. 
>>
>> It's not just Debian. (Which doesn't fit my mental model here really...)
>>
>> It's all those few-years-old computers out there. 
>>
>> It's for example Raspbian, which as of this month is still shipping 
>> Python 3.5. 
>>
>> So my boy, who's 10, says, 
>>
>> - What would you use? 
>> - Well I'd use Django (obviously) 
>> - Can I use that?
>> - Yeah... 
>>
>> If we do drop Python 3.5 I have to say, "Well, no. But you can use this 
>> old one." That's not as cool.
>> But there will be people who are more seriously affected. 
>>
>> > Who is saying, "I want to use the latest version of Django, but I want 
>> to use a really old version of Python."
>>
>> No one is saying this. The notion of versions doesn't come into it. We're 
>> well beyond the barrier-to-entry before we get there. 
>> I (just my opinion on this) think we mistake our audience if we forget 
>> this.  
>> (For this reason I don't think the deployment issue is the relevant one. 
>> It's about people learning to programme, not professionals.) 
>>
>> We can't support everything forever, and I'm as keen as anyone to push 
>> forward, but following Python is (for me) the thing we should do. 
>> I think Django's position in the Python eco-system requires it. 
>>
>> Of course if we don't, things are easier for us, yes. 
>>
>> Again, just my opinion. 
>> C. 
>> --
>> 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/19e099cf-6087-4efd-9138-d338f12bbf2c%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-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/CAFNZOJPdaWYJ9LCPZsG9dE66ka%2B8M_8Y4_%2BzMwFNz4er1pXi8w%40mail.gmail.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are 

Re: revisiting the Python version support policy

2019-01-25 Thread Tim Graham
Can you explain more about what they struggled with? Maybe there's other 
ways to solve those problems.

On Friday, January 25, 2019 at 9:43:37 AM UTC-5, Tom Forbes wrote:
>
> This message really resonated with me, especially after helping a few 
> beginners get started with Python and watching them struggle with exactly 
> this kind of thing.
>
> I'd be +1 on following Python. Looking through the diff there is not a 
> huge amount of things to remove and IMO none of them are really holding us 
> back or all that serious. We've fixed some issues with mangling cached 
> property names, some workarounds for ModuleNotFoundError/ImportError and an 
> issue with sqlite3 on 3.5.
>
> On 24 January 2019 at 20:33:42, Carlton Gibson (carlton...@gmail.com 
> ) wrote:
>
> To be honest, I'm surprised there's even one person who comes within a 
> 1000 miles of this list who's using Python 3.5. :) 
>
> My reason for thinking we should follow Python's supported versions is 
> users, and particularly beginning users, who have got they-don't-know 
> version and find a tutorial just what... no sorry need... `pip3 install 
> Django` to work, and give them the version of Django that corresponds to 
> what they see when they visit docs.djangoproject.com. 
>
> I don't agree this is theoretical at all. 
>
> It's not just Debian. (Which doesn't fit my mental model here really...)
>
> It's all those few-years-old computers out there. 
>
> It's for example Raspbian, which as of this month is still shipping Python 
> 3.5. 
>
> So my boy, who's 10, says, 
>
> - What would you use? 
> - Well I'd use Django (obviously) 
> - Can I use that?
> - Yeah... 
>
> If we do drop Python 3.5 I have to say, "Well, no. But you can use this 
> old one." That's not as cool.
> But there will be people who are more seriously affected. 
>
> > Who is saying, "I want to use the latest version of Django, but I want 
> to use a really old version of Python."
>
> No one is saying this. The notion of versions doesn't come into it. We're 
> well beyond the barrier-to-entry before we get there. 
> I (just my opinion on this) think we mistake our audience if we forget 
> this.  
> (For this reason I don't think the deployment issue is the relevant one. 
> It's about people learning to programme, not professionals.) 
>
> We can't support everything forever, and I'm as keen as anyone to push 
> forward, but following Python is (for me) the thing we should do. 
> I think Django's position in the Python eco-system requires it. 
>
> Of course if we don't, things are easier for us, yes. 
>
> Again, just my opinion. 
> C. 
> --
> 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/19e099cf-6087-4efd-9138-d338f12bbf2c%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/c25bb851-f334-48d4-bdd4-470c0ff10e2c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: revisiting the Python version support policy

2019-01-25 Thread Dan Davis
My employer is still using CPython 3.4.6 on the servers, and CPython 3.5.1
on the desktop.   I've been instrumental in developing a plan to move
forward.  I know of one established company and one start-up, by name,
where they are still using CPython 2.7 (and a horrendously old version of
Django), because it is hard to upgrade.   As long as Django has a LTS
version, such as 1.11, and soon 2.2, I think forcing an upgrade is OK.
 But it is good to be aware of what's out there.

On Fri, Jan 25, 2019 at 9:43 AM Tom Forbes  wrote:

> This message really resonated with me, especially after helping a few
> beginners get started with Python and watching them struggle with exactly
> this kind of thing.
>
> I'd be +1 on following Python. Looking through the diff there is not a
> huge amount of things to remove and IMO none of them are really holding us
> back or all that serious. We've fixed some issues with mangling cached
> property names, some workarounds for ModuleNotFoundError/ImportError and an
> issue with sqlite3 on 3.5.
>
> On 24 January 2019 at 20:33:42, Carlton Gibson (carlton.gib...@gmail.com)
> wrote:
>
> To be honest, I'm surprised there's even one person who comes within a
> 1000 miles of this list who's using Python 3.5. :)
>
> My reason for thinking we should follow Python's supported versions is
> users, and particularly beginning users, who have got they-don't-know
> version and find a tutorial just what... no sorry need... `pip3 install
> Django` to work, and give them the version of Django that corresponds to
> what they see when they visit docs.djangoproject.com.
>
> I don't agree this is theoretical at all.
>
> It's not just Debian. (Which doesn't fit my mental model here really...)
>
> It's all those few-years-old computers out there.
>
> It's for example Raspbian, which as of this month is still shipping Python
> 3.5.
>
> So my boy, who's 10, says,
>
> - What would you use?
> - Well I'd use Django (obviously)
> - Can I use that?
> - Yeah...
>
> If we do drop Python 3.5 I have to say, "Well, no. But you can use this
> old one." That's not as cool.
> But there will be people who are more seriously affected.
>
> > Who is saying, "I want to use the latest version of Django, but I want
> to use a really old version of Python."
>
> No one is saying this. The notion of versions doesn't come into it. We're
> well beyond the barrier-to-entry before we get there.
> I (just my opinion on this) think we mistake our audience if we forget
> this.
> (For this reason I don't think the deployment issue is the relevant one.
> It's about people learning to programme, not professionals.)
>
> We can't support everything forever, and I'm as keen as anyone to push
> forward, but following Python is (for me) the thing we should do.
> I think Django's position in the Python eco-system requires it.
>
> Of course if we don't, things are easier for us, yes.
>
> Again, just my opinion.
> C.
> --
> 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/19e099cf-6087-4efd-9138-d338f12bbf2c%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/CAFNZOJPdaWYJ9LCPZsG9dE66ka%2B8M_8Y4_%2BzMwFNz4er1pXi8w%40mail.gmail.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 

Re: revisiting the Python version support policy

2019-01-25 Thread Tim Graham
`pip install Django` gives the latest version of Django that's compatible 
for the current version of Python. Yes, users will have to switch versions 
at docs.djangoproject.com and they'll be in the same situation at 
docs.python.org if they're using Python 3.5. For learning Django, I'd think 
the latest LTS should be just fine. I get the sense that many intro to 
Django books are  updated at each LTS release.

At this point, I don't see much consensus so I think the default course of 
action would be to stick with the current policy unless someone wants to 
ask the technical board to vote upon the new proposal.

For what it's worth, there's a new test failure after a recent patch due to 
non-deterministic dict ordering in Python 3.5 which demonstrates the sort 
of minor annoyances that take time away from making useful improvements to 
Django.

On Thursday, January 24, 2019 at 3:33:33 PM UTC-5, Carlton Gibson wrote:
>
> To be honest, I'm surprised there's even one person who comes within a 
> 1000 miles of this list who's using Python 3.5. :)
>
> My reason for thinking we should follow Python's supported versions is 
> users, and particularly beginning users, who have got they-don't-know 
> version and find a tutorial just what... no sorry need... `pip3 install 
> Django` to work, and give them the version of Django that corresponds to 
> what they see when they visit docs.djangoproject.com. 
>
> I don't agree this is theoretical at all. 
>
> It's not just Debian. (Which doesn't fit my mental model here really...)
>
> It's all those few-years-old computers out there. 
>
> It's for example Raspbian, which as of this month is still shipping Python 
> 3.5. 
>
> So my boy, who's 10, says, 
>
> - What would you use? 
> - Well I'd use Django (obviously) 
> - Can I use that?
> - Yeah... 
>
> If we do drop Python 3.5 I have to say, "Well, no. But you can use this 
> old one." That's not as cool.
> But there will be people who are more seriously affected. 
>
> > Who is saying, "I want to use the latest version of Django, but I want 
> to use a really old version of Python."
>
> No one is saying this. The notion of versions doesn't come into it. We're 
> well beyond the barrier-to-entry before we get there. 
> I (just my opinion on this) think we mistake our audience if we forget 
> this.  
> (For this reason I don't think the deployment issue is the relevant one. 
> It's about people learning to programme, not professionals.) 
>
> We can't support everything forever, and I'm as keen as anyone to push 
> forward, but following Python is (for me) the thing we should do. 
> I think Django's position in the Python eco-system requires it. 
>
> Of course if we don't, things are easier for us, yes. 
>
> Again, just my opinion. 
> C. 
>

-- 
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/33e013be-48ab-4dfe-9c92-f8047538654e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: revisiting the Python version support policy

2019-01-25 Thread Tom Forbes
This message really resonated with me, especially after helping a few
beginners get started with Python and watching them struggle with exactly
this kind of thing.

I'd be +1 on following Python. Looking through the diff there is not a huge
amount of things to remove and IMO none of them are really holding us back
or all that serious. We've fixed some issues with mangling cached property
names, some workarounds for ModuleNotFoundError/ImportError and an issue
with sqlite3 on 3.5.

On 24 January 2019 at 20:33:42, Carlton Gibson (carlton.gib...@gmail.com)
wrote:

To be honest, I'm surprised there's even one person who comes within a 1000
miles of this list who's using Python 3.5. :)

My reason for thinking we should follow Python's supported versions is
users, and particularly beginning users, who have got they-don't-know
version and find a tutorial just what... no sorry need... `pip3 install
Django` to work, and give them the version of Django that corresponds to
what they see when they visit docs.djangoproject.com.

I don't agree this is theoretical at all.

It's not just Debian. (Which doesn't fit my mental model here really...)

It's all those few-years-old computers out there.

It's for example Raspbian, which as of this month is still shipping Python
3.5.

So my boy, who's 10, says,

- What would you use?
- Well I'd use Django (obviously)
- Can I use that?
- Yeah...

If we do drop Python 3.5 I have to say, "Well, no. But you can use this old
one." That's not as cool.
But there will be people who are more seriously affected.

> Who is saying, "I want to use the latest version of Django, but I want to
use a really old version of Python."

No one is saying this. The notion of versions doesn't come into it. We're
well beyond the barrier-to-entry before we get there.
I (just my opinion on this) think we mistake our audience if we forget
this.
(For this reason I don't think the deployment issue is the relevant one.
It's about people learning to programme, not professionals.)

We can't support everything forever, and I'm as keen as anyone to push
forward, but following Python is (for me) the thing we should do.
I think Django's position in the Python eco-system requires it.

Of course if we don't, things are easier for us, yes.

Again, just my opinion.
C.
--
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/19e099cf-6087-4efd-9138-d338f12bbf2c%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/CAFNZOJPdaWYJ9LCPZsG9dE66ka%2B8M_8Y4_%2BzMwFNz4er1pXi8w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: revisiting the Python version support policy

2019-01-24 Thread Carlton Gibson
To be honest, I'm surprised there's even one person who comes within a 1000 
miles of this list who's using Python 3.5. :)

My reason for thinking we should follow Python's supported versions is 
users, and particularly beginning users, who have got they-don't-know 
version and find a tutorial just what... no sorry need... `pip3 install 
Django` to work, and give them the version of Django that corresponds to 
what they see when they visit docs.djangoproject.com. 

I don't agree this is theoretical at all. 

It's not just Debian. (Which doesn't fit my mental model here really...)

It's all those few-years-old computers out there. 

It's for example Raspbian, which as of this month is still shipping Python 
3.5. 

So my boy, who's 10, says, 

- What would you use? 
- Well I'd use Django (obviously) 
- Can I use that?
- Yeah... 

If we do drop Python 3.5 I have to say, "Well, no. But you can use this old 
one." That's not as cool.
But there will be people who are more seriously affected. 

> Who is saying, "I want to use the latest version of Django, but I want to 
use a really old version of Python."

No one is saying this. The notion of versions doesn't come into it. We're 
well beyond the barrier-to-entry before we get there. 
I (just my opinion on this) think we mistake our audience if we forget 
this.  
(For this reason I don't think the deployment issue is the relevant one. 
It's about people learning to programme, not professionals.) 

We can't support everything forever, and I'm as keen as anyone to push 
forward, but following Python is (for me) the thing we should do. 
I think Django's position in the Python eco-system requires it. 

Of course if we don't, things are easier for us, yes. 

Again, just my opinion. 
C. 

-- 
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/19e099cf-6087-4efd-9138-d338f12bbf2c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: revisiting the Python version support policy

2019-01-24 Thread Ryan Hiebert
On Thu, Jan 24, 2019 at 11:29 AM Tim Graham  wrote:

> Let's hear from people who find the current Python support policy
> insufficient for their needs.
>

Agreed. I'm not one of them, dropping 3.5 support disadvantages me in no
way. I don't use it in production or in development, and would have no
problem with 3.5 support being dropped.

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


Re: revisiting the Python version support policy

2019-01-24 Thread Tim Graham
It's interesting to me that no one (besides Claude -- and that's based on 
his ability to contribute to Django) has indicated that they care about 
Python 3.5 support in their deployments of Django 3.0... so I wonder if 
there is really a strong need for it. Who is saying, "I want to use the 
latest version of Django, but I want to use a really old version of 
Python." ... then 8 months later when Django 3.1 is released ... oh, now I 
still want to use the latest version of Django but I can't because my 
Python is too old.

It's an analogous situation to Django 2.0 and Python 3.4. From the Django 
2.0 release notes, "Django 2.0 will be the last release series to support 
Python 3.4. If you plan a deployment of Python 3.4 beyond the end-of-life 
for Django 2.0 (April 2019), stick with Django 1.11 LTS (supported until 
April 2020) instead. Note, however, that the end-of-life for Python 3.4 is 
March 2019." Is anyone in this situation? As I argued before, I think it's 
better to drop support for versions of Python after an LTS so that Django 
users aren't "stranded" on some unsupported Django because their Python is 
too old.

If we amend the policy as suggested, then I think Django 2.1 (end of 
mainstream support in April) would have gotten Python 3.4 support (end of 
support in March) -- did anyone miss that?

It's impossible to quantify how much work would be required to support the 
oldest version of Python an extra 8 or 16 months in Django's branch. It's 
not only keeping around workarounds for that older Python, but also 
developing new features with workarounds... and not being able to use new 
features in Python (or having to vendor them in Django, which then 
generally requires a deprecation of that vendored code). I think the 
justification to adopt a new policy should be clear. Currently I see "it 
would be nice" theoretical arguments. Let's hear from people who find the 
current Python support policy insufficient for their needs.

On Thursday, January 24, 2019 at 12:04:35 PM UTC-5, Ryan Hiebert wrote:
>
>
> On Thu, Jan 24, 2019 at 10:55 AM Adam Johnson > 
> wrote:
>
>> So, phrasing... maybe... as a draft: "Typically, we will support a Python 
>>> version unless it will be end of life before the corresponding version of 
>>> Django is outside of mainstream support. For example, Python 3.5 security 
>>> support ends September 2019, whilst Django 3.1 ends mainstream support in 
>>> April 2021. Therefore Django 3.0, which is end of life August 2019 is the 
>>> last version to support Python 3.5." 
>>
>>
>> +1. A subtle change on the existing policy but it makes a difference.
>>
>
> That seems better to me as well. It only ties us to the support policy of 
> Python, not various special-cased distributions. My concern, though, is 
> that it weakens semantic versioning a bit, so we should do it carefully. We 
> don't follow it precisely, but if we drop support for a version of Python, 
> that seems to me like it would qualify as a breaking change, and should be 
> preferred to be done when changing major versions after an LTS release. If 
> that is deemed to not be a significant concern, then I think this proposed 
> policy is a reasonable one.
>

-- 
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/afff11b1-5924-45a0-b204-99a2a04f5f39%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: revisiting the Python version support policy

2019-01-24 Thread Adam Johnson
>
> So, phrasing... maybe... as a draft: "Typically, we will support a Python
> version unless it will be end of life before the corresponding version of
> Django is outside of mainstream support. For example, Python 3.5 security
> support ends September 2019, whilst Django 3.1 ends mainstream support in
> April 2021. Therefore Django 3.0, which is end of life August 2019 is the
> last version to support Python 3.5."


+1. A subtle change on the existing policy but it makes a difference.

On Thu, 24 Jan 2019 at 08:16, Carlton Gibson 
wrote:

> Sorry I mistyped. " Python 3.5 security support ends September 2020" (but
> you get the point.)
>
> --
> 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/ac50c67c-51a8-4c94-9505-c19fc6fd7cfc%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/CAMyDDM1-jtxRXNXjcvr8ALPXTAh8ss-LN%3DniAODm1hNQ9nwEWA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: revisiting the Python version support policy

2019-01-24 Thread Ryan Hiebert
On Thu, Jan 24, 2019 at 10:55 AM Adam Johnson  wrote:

> So, phrasing... maybe... as a draft: "Typically, we will support a Python
>> version unless it will be end of life before the corresponding version of
>> Django is outside of mainstream support. For example, Python 3.5 security
>> support ends September 2019, whilst Django 3.1 ends mainstream support in
>> April 2021. Therefore Django 3.0, which is end of life August 2019 is the
>> last version to support Python 3.5."
>
>
> +1. A subtle change on the existing policy but it makes a difference.
>

That seems better to me as well. It only ties us to the support policy of
Python, not various special-cased distributions. My concern, though, is
that it weakens semantic versioning a bit, so we should do it carefully. We
don't follow it precisely, but if we drop support for a version of Python,
that seems to me like it would qualify as a breaking change, and should be
preferred to be done when changing major versions after an LTS release. If
that is deemed to not be a significant concern, then I think this proposed
policy is a reasonable one.

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


Re: revisiting the Python version support policy

2019-01-24 Thread Carlton Gibson
Sorry I mistyped. " Python 3.5 security support ends September 2020" (but 
you get the point.)

-- 
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/ac50c67c-51a8-4c94-9505-c19fc6fd7cfc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: revisiting the Python version support policy

2019-01-24 Thread Carlton Gibson
> My idea was to set the policy as : when a new major Django version is 
released, it supports all current supported versions of Python.

I agree with this — more or less...

Python 3.5 is officially supported for the entire life of Django 3.0. (It 
goes EOL a month after Django 3.0) 
(c.p [0] vs [1])

[0]: https://devguide.python.org/#status-of-python-branches
[1]: https://www.djangoproject.com/download/#supported-versions

So I think we SHOULD support Python 3.5 for Django 3.0.
(Yes, push forward, but pushing people off of supported versions seems a 
bit over-zealous, and I think we'll be shooting ourselves in the foot, due 
to the need to repeatedly handle, probably valid, pushback.)

However Django v3.1 will be released JUST A MONTH before Python v3.5 goes 
EOL. As such I don't want to support it there. 

So, phrasing... maybe... as a draft: "Typically, we will support a Python 
version unless it will be end of life before the corresponding version of 
Django is outside of mainstream support. For example, Python 3.5 security 
support ends September 2019, whilst Django 3.1 ends mainstream support in 
April 2021. Therefore Django 3.0, which is end of life August 2019 is the 
last version to support Python 3.5." 

i.e. What Claude said except "...unless it's just about to be dropped". 

I know we backported support for Python 3.7 to Django 1.11 but I think this 
should apply to the LTS as well. 

> ...they've already made the choice to prioritize stability rather than 
access to new versions, and this is the consequence of the choice...


Just as an additional point, Django third-party apps as a rule try to 
follow Django's support versions policy. (i.e. Currently supporting 1.11+) 
This works well for people. I think the situation is equivalent with 
regards to Django and Python. 

Kind Regards,

Carlton

-- 
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/dbab5867-b4aa-4dbe-a952-b8fbd9657e3b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: revisiting the Python version support policy

2019-01-23 Thread Claude Paroz
Le mercredi 23 janvier 2019 08:31:17 UTC+1, James Bennett a écrit :
>
> 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.
>

You're right, the fact that this is Debian or any other distro doesn't 
matter here. My idea was to set the policy as : when a new major Django 
version is released, it supports all current supported versions of Python.

> People who want to contribute to Django probably already need to solve 
the problem of having multiple Python versions installed...

That's not my experience. It was during Python 2/3 coexistence, but now if 
you develop with any Python 3 version, the rare cases where Python version 
incompatibilities happen are catched by the CI runs.

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/3160ff66-d0cf-44a4-af00-1330854b8295%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: revisiting the Python version support policy

2019-01-22 Thread 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.


Re: revisiting the Python version support policy

2019-01-22 Thread 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

2019-01-22 Thread 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

2019-01-22 Thread 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

2019-01-22 Thread 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 

Re: revisiting the Python version support policy

2019-01-22 Thread 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

2019-01-22 Thread 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: revisiting the Python version support policy

2019-01-22 Thread 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

2019-01-21 Thread Jason Johns
In addition, with tools like https://github.com/pyenv/pyenv available that make 
changing the currently applicable python version in any given shell extremely 
easy, I feel pinning support to a specific operating system version, however 
stable, is not the optimal approach 

-- 
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/211103b2-ecb4-4e3e-bf84-85cd049b47ad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: revisiting the Python version support policy

2019-01-21 Thread Ryan Hiebert
I don't feel like my voice should have much weight, but I think that the
policy as written is better. Debian aims to be stable long term, and for us
to match Debian, especially when not in our LTS releases, seems excessive
to me.

On Mon, Jan 21, 2019 at 9:56 AM 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/ce5f3cdb-a623-4bcc-a661-bf88d91a5a7f%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/CABpHFHTSo%3D80GWdA6kLqk%3DXBxFa6s1d3V%3D_LBmoj4oCJQwJMLA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.