Live data from Hacker News

Removing Python 2.x support from Django for version 2.0

github.com

331–340 of 413 posts

Re: Removing Python 2.x support from Django for version 2.0

#331
post #62

Earlier quoted context omitted.

> It's going to be more and more of a burden for the developers to maintain compatibility with a 7-year old version of Python. That's the version of Python that most of their users actually use -- with no major plans of mass updating.

The ruby community moved on after their last breaking change in less than 2 years. The JS community deals with breaking changes every 3 months or so. From Python 3.0 the end of support, you have __15 freaking years__, warnings, tutorials and excellent tooling at your disposal. Oh, on a free software. Half made by some charity workers. Now you made a choice, and there are very good reasons to have made it. We won't cr…

Ruby also BROKE A LOT LESS, and offered immediate, tangible reasons to upgrade.

Re: Removing Python 2.x support from Django for version 2.0

#332

Earlier quoted context omitted.

> This isn't a numbers contest. And yet you complained about my many comments. If you just had an issue with their content, you could have said so instead of that, and with specific arguments not just "stop" and "lalala hands in the ears, I don't want to hear you". > Unlike yours, none of my comments are shitting on the efforts of volunteers that are doing their best to keep people like you happy and making money usi…

> If you just had an issue with their content, you could have said so I did. I did not think I needed an argument to ask you to stop bringing such an incredibly negative attitude to the table. > You don't know what I've paid I was referring to Django, to be clear. And whatever you've paid, it's in donations -- that's great! But if you want to see support, you'll need to directly pay people to maintain that support. I…

>I did. I did not think I needed an argument to ask you to stop bringing such an incredibly negative attitude to the table.

Not argument or not (and as you said, you didn't think you needed one) you don't have the right to tell me to stop bringing my opinion to the table.

Whether you think it's negative or not, it's not your place to conduct the discussion on HN. Just state your case, and let others state their case. I wouldn't even have left all those comments if I didn't have to defend myself, as most as responses to your demands that I "just stop" and your accusations.

>I was referring to Django, to be clear. And whatever you've paid, it's in donations -- that's great! But if you want to see support, you'll need to directly pay people to maintain that support. I believe in fact you yourself said that before, here on HN, about other tech.

I didn't force anybody to provide me support. I didn't even ask anybody for support for me specifically, and I didn't hold a gun to anybody's head on the matter.

I criticized projects dropping support for Python 2.x, and made my case. Criticizing is not the same as demanding.

>This is basically saying "I do not care for python 3 features, therefore Python 2 should continue being supported even longer [because I have an old codebase to maintain]"

Which is a perfectly reasonable argument, only you omitted the part where I said that the majority of Python users seem to be in the same position (and thus such a drop could be bad for Django itself -- if people are forced to migrated an old project, they might as well bite the bullet and try something else entirely, Node for example).

>The argument in a nutshell is that because the transition is hard, the Python team should just give up on the transition and support both. It's an argument I've heard before. The reason it doesn't hold water is because doing so would completely kill the language, for good.

The transition itself might kill the language, it has already taken far too long with meagre results thus far. It's not impressive that "nearly all popular libraries" have been ported to 3, when it's close to 10 years past 3.x and the majority of users are still on 2.

In any case, there are ways to "support both" that don't kill anything, e.g. making a "merged" Python 2/3 hybrid release that runs both 2.x and 3.x codebases, and is the official CPython going forward.

Or supporting 2.x as longer as needed for 60 or 70% of the users to migrate, as opposed to an arbitrary optimistic cutoff date in 2020, set when people still thought 3.x will get quickly adopted.

>now, we're on the final stretch and the remaining complaints are from people in similar situations as you: Large Python 2 codebase to maintain, therefore can't switch, therefore "please give us more time, and by more time I mean just forget Python 3 ever happened and come back"

Sounds perfectly reasonable. If the largest stakeholders (people with actually large Python codebases) can't speak up, then who can? Newbs that started some small greenfield project with 3.x?

Re: Removing Python 2.x support from Django for version 2.0

#333
post #247

Earlier quoted context omitted.

Python 3 is a seriously misguided project. It's got tons of newer-to-Python fans (your HN downvoter demographic), and tons of silent-majority "real-world" users especially in scientific programming who just don't like it. I moved to 3.4 a year ago and, as a data scientist, I have to say I find nothing in 3 to be better than 2, other than the extremely marginal default float arithmetic. I may be wrong for web developm…

> It's got tons of newer-to-Python fans (your HN downvoter demographic) Please don't make generalizations about people who disagree with you just to score a rhetorical point, and please don't break the HN guidelines by going on about downvotes: https://news.ycombinator.com/newsguidelines.html .

This particular subject invites heavy bias due to vote herding, and I am proud to call it out and to speak an unpopular but fair opinion nonetheless.

http://www.google.co.uk/url?sa=t&source=web&cd=1&ved=0ahUKEw...

As a moderator you appear guilty of partisanship because I note a conspicuous absence of action against a clear mob suppression of the 2.7 view.

Re: Removing Python 2.x support from Django for version 2.0

#334

Earlier quoted context omitted.

When you say "Django is not RoR", are you saying Django doesn't break backwards compatibility but Ruby on Rails does? If so, I have to very strongly disagree. It's almost mind boggling to me how much they break backwards compatibility as a framework. They usually warn users with a deprecation warning in one version and then they make the backwards incompatible change in the next version, but the sheer amount of these…

Oh they do break, but it's a much slower process than RoR (as you described) IIRC the most impacting changes I remember were in Config, replacement of South with a native solution and some timezone issues

The upgrade process of south was pretty shitty.

The documentation was telling something like: Ensure you applied all previous migrations and then start from scratch. Thats not an upgrade path. It may work for standalone web applications, but I have a python project (packaged as deb/rpm package and using the packaged django version of different distributions) that should work with multiple django versions and the user may upgrade the django version at any point.

I had to write raw sql statements to get the mirgration status of south (after the upgrade, without a working version of south anymore) and "fake" apply the migrations of the new native solution.

Re: Removing Python 2.x support from Django for version 2.0

#335
post #117

Earlier quoted context omitted.

> the Python Software Foundation won't let them use the name Python That's how trademarks are supposed to work; they must go after anyone using without permission or they lose it.

Or they could give permission.

The reason you have a trademark is to enforce rights to the name and prevent confusion. If suddenly Python 2.8 would appear it would be easily confused for official release. If it had flaws they often would also land on the official release.

That's why if you want to make a fork you're free to do so, but you need to make a different name. If it's something people desire it will be used, you can't just ride on the popularity of the name. If your fork has different name and is not popular, it means that there was not much interest in it, period.

Some of successful forks:

openOffice -> LibreOffice

MySQL -> MariaDB

ZFS -> OpenZFS

Re: Removing Python 2.x support from Django for version 2.0

#336
post #182

I have a Python 2.7 project that has been running smoothly for many years now and I'm having trouble finding a reason to upgrade to Python 3. The project uses the unicode type to represent all strings, and encodes/decodes as necessary (usually to UTF-8) when doing I/O. I haven't really had any of the Unicode handling problems that people seem to complain about in Python 2. Can someone explain what benefit I would act…

You gain access to continued language support in 2020. New features involving strings will have less risk of bugs. The "range" function is more memory efficient. Integer division automatically floors, reducing bug risk. Dictionaries with guaranteed ordering. Thousands separator in string formatting. Bit length on integers. Combinations with replacement on itertools. New, faster I/O library and faster json. Concurrent…

You forgot functools.lru_cache. I've found in some Python 2.7 projects you can speed things up with a hacky dictionary-cache, but the proper functools.lru_cache gives better results and is far more flexible.

Re: Removing Python 2.x support from Django for version 2.0

#337

Earlier quoted context omitted.

For me, the google api client libraries, and AWS Lambda. That last one isn't totally Django related, but we use it for certain service calls, and it'd be nicer to be able to maintain one version of the language across the django app and related services. We ended writing a service in PHP to use Google's APIs, and are mostly using Scala or JS instead of Python for the Lambda services because this project is basically…

The Google API Client is at least Python 3.4 compatible: https://github.com/google/google-api-python-client/ I see only one Py3 bug is the open issues. And I think even their ancillary library Python Flags is now officially Py3 compatible, even though there has been a Py3 fork of it for years.

Nice! Looks that was just added in December, prior to that they had a statement saying it would probably work in 3.3+ but wasn't tested.

I didn't mean the one literally called google-api-python-client though (forgot they had that, ha). The googleads-python-lib is the critical one for me. PyPI says it supports 3+, but do one search in the repo for "print" and you'll see that's clearly not true.

Looking through the history, seems like they've claimed support for it for a while. We've tried it twice and had issues both times, though I never tried it in Py2, so maybe it just has problems in general.

Re: Removing Python 2.x support from Django for version 2.0

#338
post #331

Earlier quoted context omitted.

The ruby community moved on after their last breaking change in less than 2 years. The JS community deals with breaking changes every 3 months or so. From Python 3.0 the end of support, you have __15 freaking years__, warnings, tutorials and excellent tooling at your disposal. Oh, on a free software. Half made by some charity workers. Now you made a choice, and there are very good reasons to have made it. We won't cr…

Ruby also BROKE A LOT LESS, and offered immediate, tangible reasons to upgrade.

The reasons to upgrade are often dependent upon your usage case. To me, the Unicode improvements are reason enough on their own before you even get into the other great stuff (async work, type hinting, stdlib cleanup, pyc rework, etc).

asyncio is going to be a slow build, as the ecosystem starts unifying around it. But as that happens, we'll be much better off for it.

Re: Removing Python 2.x support from Django for version 2.0

#339
post #279

Earlier quoted context omitted.

I don't have any projects using Django but they have an LTS model - surely you don't need to update to avoid being vulnerable? Just security patches?

For three years, if you release your project the day the LTS comes out.

Well the new model will have a new LTS every 2 years, with guaranteed compatibility as long as you didn't have any deprecation warnings. So you get 2 years to fix warnings, then a guaranteed working new version. I find it hard to believe anybody is doing anything better in this space.
Post reply on HN