Live data from Hacker News

Removing Python 2.x support from Django for version 2.0

github.com

91–100 of 413 posts

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

#91
post #21

Earlier quoted context omitted.

Interestingly, I have the exact opposite view on Django. I hate their API and overall architecture, which I find to be the result of glueing features on top of features for many years. The internal code also is just like that: looks like every single method is riddled with out-of-band conditionals, which is the result of a community that prefers to hack things to work, instead of rethinking/refactoring.

> instead of rethinking/refactoring. And breaking backwards compatibility Django is not RoR. Their users rely on being able to upgrade seamlessly. The overall Api makes sense, there are some rough corners (yes Sites, I'm talking about you) the docs are ok once you get the hang of them

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 kind of changes makes upgrading an infuriating process. Especially when upgrading a large codebase.

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

#92
post #47
post #6

This call has been made a while back, and it makes perfect sense. Python 2 is slowly being EOL'd and if you're starting a brand new Django project there's no reason on earth you should choose Python 2 anymore. Sure legacy projects still need support and for that they get the 1.11 LTS, but otherwise it's really time to move on.

> and if you're starting a brand new Django project there's no reason on earth you should choose Python 2 anymore. How about millions of lines of code in your company in Python 2, and several Python 2 based services and websites? Why on earth will you go to Python 3 at huge rewriting costs? To get some fancy syntactic sugar and improved unicode?

>> and if you're starting a brand new Django project there's no reason on earth you should choose Python 2 anymore. > Why on earth will you go to Python 3 at huge rewriting costs?

If you're starting a brand new Django project you're not rewriting anything. If you're rewriting something, it's not really new.

My company is a Django shop and while we have no intention of upgrading Python 2.x codebases to 3, we do start all our new projects on Python 3. It just doesn't make sense not to do it.

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

#93

Says who?? Someone with delusions of grandeur, obviously. Because that's not up to anyone to say. Python 2 is obviously NOT going away any time soon. You can't just look at reality and claim the opposite just because it pleases you. Python 2 is here to stay and is in MUCH better shape than Python 3, in terms of actual production usage globally. Python 3 is a bad joke that someone wants to force down people's throats…

Nope, Python 3 is a sane upgrade to a sane language bringing many enhancements to the consistency and reliability of Python. And it is being used in many production systems already.

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

#94
post #58
post #11

Earlier quoted context omitted.

This sounds like a fork. Nothing need stop someone from forking and maintaining CPython 2.x. Open source is a do-ocracy. But I doubt it'd be worth it. Python 3 is getting great traction and is a fundamentally better language.

> This sounds like a fork. Python 3 is already a fork.

It's a major release.

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

#95

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…

What py3 does is it enforces the things that py2 only suggests as far as unicode goes. That means on py2 you can go for the proper handling and if you did do everything right, then py3 migration should be almost boring.

The difference is when you didn't handle all the cases correctly. In that situation Py2 will silently do either the right, or the wrong thing and you'll never know. Py3 will likely throw an extension and tell you where the issue is.

So if you're handling lots of unicode text and think you've handled all the string correctly already - that's the reason to move. Now you'll be sure it's correct. The problem with py2 wasn't so much that it was handling anything badly - it was that the default, easy way was incorrect and just waiting to blow up in peoples' faces. (or maybe just silently corrupt something)

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

#96

Says who?? Someone with delusions of grandeur, obviously. Because that's not up to anyone to say. Python 2 is obviously NOT going away any time soon. You can't just look at reality and claim the opposite just because it pleases you. Python 2 is here to stay and is in MUCH better shape than Python 3, in terms of actual production usage globally. Python 3 is a bad joke that someone wants to force down people's throats…

Nope, Python 3 is a sane upgrade to a sane language bringing many enhancements to the consistency and reliability of Python. And it is being used in many production systems already.

Congratulations, you've been brainwashed.

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

#97

Earlier quoted context omitted.

the benefit is that all the wasted energy that went into all the useless 3.x stuff, could have been spent on advancing Python's speed, multicore, or GPU programming capabilities. Instead, for the single use case where Python is clearly the dominant language (for pure network-effect reasons), namely scientific programming, we have been at a standstill for years. In other words, under current stewardship, Python is goi…

Interesting that you're looking for those improvements in CPython. From your list (IMO): speed and multicore are going to stay where they are in CPython - GIL is unlikely to be removed, because it's basically part of the behaviour right now. There were a few attempts, but it seems nobody even tries anymore. (and I'm fine with that) Maybe pypy, grumpy, or others will do this instead. I'm not sure why you expect GPU fr…

The GIL is encoded into practically every C API of the interpreter. It's not going away in CPython, and at the very least any Python implementation supporting CPython extensions will have a global lock for calls into extensions.

And even if (there were patches for removing the GIL already around in the 90s): All of the approaches and patches shown so far significantly degraded single-threaded performance, which matters to way more applications than the GIL, which typically is not a significant limit to using multiple cores/processors.

"Teh GIL" is a very, very overblown issue, and is -- I don't want to be condescending here, but well -- usually brought up by people that have little experience writing software that makes effective use of multiple-many cores.

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

#98

Earlier quoted context omitted.

the benefit is that all the wasted energy that went into all the useless 3.x stuff, could have been spent on advancing Python's speed, multicore, or GPU programming capabilities. Instead, for the single use case where Python is clearly the dominant language (for pure network-effect reasons), namely scientific programming, we have been at a standstill for years. In other words, under current stewardship, Python is goi…

Interesting that you're looking for those improvements in CPython. From your list (IMO): speed and multicore are going to stay where they are in CPython - GIL is unlikely to be removed, because it's basically part of the behaviour right now. There were a few attempts, but it seems nobody even tries anymore. (and I'm fine with that) Maybe pypy, grumpy, or others will do this instead. I'm not sure why you expect GPU fr…

[deleted]

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

#99
Oh my god stop. You're all over this thread. What bit you?

This is the price you pay for staying on an old version. You do not get to stick to an old version AND demand that others do too.

You CAN stay on Python 2. You CAN stay on Django 1.11. It's LTS. So is Python 2.7. You get to use both until 2020 with no issues. After that, not upgrading is a technical debt that will start to accrue, faster and faster as you can no longer use recent versions of various software.

You are free to make your infrastructure immutable; you then become responsible for it of course. And the money you're not willing to spend porting to Python 3 today will be money you spend on costs related to being on outdated infrastructure, years in the future. That's a tradeoff. Banks do it a lot I hear. A bunch of companies still use ancient hardware and technologies nobody would think of starting a business with today. These companies make billions.

You know what the employees of these companies aren't doing? They're not bitching on HN that the tech they're using is no longer supported.

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

#100
post #11

Earlier quoted context omitted.

This sounds like a fork. Nothing need stop someone from forking and maintaining CPython 2.x. Open source is a do-ocracy. But I doubt it'd be worth it. Python 3 is getting great traction and is a fundamentally better language.

Python 3 is already a fork. The problem is that Python 2 cannot evolve freely alongside Python 3, because even if someone wants to maintain it and keep releasing versions, the Python Software Foundation won't let them use the name Python (there was a post some weeks ago about someone who actually tried). So there is no free competition between 2 and 3. 2 has been basically killed by a decision from above. Don't get m…

Python 3 is not a fork. It is a major release. A continuation of the same language, by the same people, with very little change in the core concepts. A major release with some backward incompatibilities doesn't constitute a fork.

The previous version is being sunsetted, as is common for legacy software. By the time 2.7 is EOL'd, it will have enjoyed a decade of active development and maintenance. That's just one version of Python.

If there were a compelling enough argument for a fork, it would happen and a new name would be chosen. But alas, it makes very little sense for the wider world.

It's not difficult to write software that works with Python 2 and 3. It's just becoming less and less worth it, as evident by announcements like this Django 2.0 one. The scales have tipped towards Python 3.

Post reply on HN