Widen scope from scientific stack, add Django

[Zac-HD]

Fixes #21, related to #23.

Django seems to fit this so well that it's just silly to leave it out, especially when it has already dropped Python 2 for new releases. @timgraham should probably assent before this is merged though - I have no relevant authority beyond noticing that Django seems to have said almost exactly the same things!

[takluyver]

Thanks. Yes, I think it might be time to broaden the scope of this.

We started it with the scientific Python world because that's what we're familiar with: we know that all the key projects have supported Python 3 for a while, and that there's an appetite for dropping Python 2 support. But we've already added a few projects from the broader Python world (Kivy, xonsh, Zulip).

For Django specifically, we would want agreement from the people who run it. Their support timeline is definitely compatible with the statement, but it should be their decision to support it. Maybe it's appropriate to post to their mailing list or issue tracker to ask about this?

[timgraham]

This was discussed briefly on the django-developers mailing list and there wasn't a consensus that joining would have any value.

[Carreau]

Thanks Zac for bringing that up, and Tim for responding.

Tim, the position of the Django developers is completely understandable, and we will of course not add you without your accord. From a couple of conferences I've participated to, I often get asked why Django have not signed and been told that a large list of projects in a single place is often a good argument to present to management to "why python 3", and Django on this list would help.

Also unlike what is said on linked thread, our goal is not to shame Python 2 users, and we have a section dedicated to libraries author only on how to minimize the disruption for Python 2 users (we should likely promote this section more). For example , Django setup.py is missing the requires_python ='>=3.4' which tell pip not to try to install Django 2.0 on Python 2... which would have made installing django less disruptive for python 2 users.

Adding Django to the list may not have lot of value for Django itself, but may have a lot of impact for users and dev trying to convince other of the necessity of migrating.

Thanks, and if the discussion restart in your project and you come to a consensus please let us know.

[takluyver]

Fair enough. If there's further discussion about it, I see the value as:

• Giving downstream users notice in plenty of time that we're going to end Python 2 support, so they can plan around that.
• Related: giving developers in organisations a clear argument they can take to management: it's worth spending time porting to Python 3, because that's what open source projects will be supporting.
• Supporting other projects that want to take advantage of Python 3 features, by reassuring them that they're not going to be alone.

Django is big enough that it can probably do all of this by itself, but the combined statement is important for smaller projects. We have a louder voice by speaking together - and that's probably true even for a project as big as Django.

[takluyver]

@Carreau they're working on adding requires_python : django/django#9413 (unfortunately this wasn't done before the 2.0 release - I don't think it can be changed retrospectively).

[Carreau]

@Carreau they're working on adding requires_python : django/django#9413 (unfortunately this wasn't done before the 2.0 release - I don't think it can be changed retrospectively).

Ah thanks ! commented there.

[mscuthbert]

Just for one data point on how Django affects the scientific Python community: we at music21 decided to eventually drop support for Python 2 only once we say that Django was doing it, and we waited for the massive set of commits on Django that removed Py2 support from the "master" branch before we went ahead and did the same thing, so I would think it's fine to broaden the scope to at least something like "scientific python packages that have committed to dropping Py2 support or major open-source packages in any field that have already dropped Py2 support (or never supported it in the first place)". If we make the site's concept of a "statement" either a commitment (which requires consent of the package developers) or an action (which is public record and does not require affirmative consent) then I think it will keep with the spirit of the site while broadening it to give the value that @takluyver noted above.

[takluyver]

I'd prefer to keep the scope simple, whether that's scientific Python or all Python - I don't want to start carving out exceptions for 'major projects'.

If we get more projects that drop Py2 support but choose not to join the statement, I might consider adding a purely informational section ("These projects also have a timetable for the end of Python 2 support, but are not part of this statement"). But I don't think that makes sense for one project, even one as big as Django. And I hope that Django might consider it again now that Django 2.0 is out - their previous discussion was over a year ago.

[asmeurer]

I've long felt that the site shouldn't just be limited to scientific projects. So I'm +1 to the changes to the main statement.

Django shouldn't be added unless it's by permission from the core developers. The whole point of the statement is that it's a statement from the developers. If the developers don't sign off on it, it shouldn't be added.

To the Django developers: if the statement comes off as smug, please suggest how we can improve that. It is not our intention at all to be smug. The goal of the statement is to inform users when Python 2 support will be ending for critical projects, and to create a critical mass of projects that agree to end Python 2 support by 2020 (or earlier).

[takluyver]

@Zac-HD do you want to knock off the commit adding Django (or make a new PR if that's easier), and we can discuss the wording changes to make it more broadly applicable?

[Zac-HD]

I've got way too many projects to do much before January, but happy to make a pull when I have time - how about we close this and work out a rough form of words in #21, to keep the discussions approximately on-topic.

[takluyver]

OK, thanks :-)

[Carreau]

I started #99 (including only the first commit on this PR) as we got a couple more indication that widening the scope of the statement would be good. No hurry though, and @Zac-HD if/when you want to take over again we'll be happy to have you do so !