I speculate that the latest Django 1.x will remain used - and possibly the most used - for a lot, lot of time.
There is an awful lot of hyperbole around the difficulty of upgrading from python 2 to 3, however with the latest changes in 2.7 and 3.6 the gap isn't as big as you expect. I converted our (admittedly not massive) 35,000loc Django project from 2 to 3 in about four hours, starting with with 2to3 tool then working though test failures it wasn't nearly as bad as I was expecting. Most of the issues were as I expected around the new string handling, but as soon as something broke, I knew before looking at the code what the problem was.
- We already have linting in place that encourages Python 3 compatibility (and have no linter warnings on master).
- We already use six for moved modules.
- And we have a test suite that is not exhaustive, but 'good enough' to find the common patterns of bug for this kind of thing.
- We also have a style-guide that favours the ability to find-replace project wide with relative safety.
- We don't have much 'math heavy' code that will fail with the changes in operations in Python 3.
- We already use unicode for the majority of strings.
- We don't use my Python networking code directly, it's mostly just Requests (so a lot of the moved modules don't apply).
This excludes the upgrading of dependencies, I think that's where we will spend more time, but the actual Python 3 transition for the main codebase should be ok, mostly because of the effort we've put into style and review since it started ~5 years ago.
+1. IMO this is the 2nd most overblown python issue next to the GIL.
It's also not actually that difficult to maintain code that works on both.
Upgrading Django OTOH has caused me quite a bit more pain over the years.
That's not what the announcement is about. Django worked with python 3.x for a long time already. Now they're actually going to drop 2.7, so back to one supported version.
The support should have been cut a long time ago and now we wouldn't be having this discussion.
At my last job they were still using Django 1.6 when I quit last year. Updating to a new version takes a lot of manhours. Rewriting the codebase in a new language (which basically what Python 2 -> Python 3 transition is) would be completely out of the question.
Not even close to rewriting in a new language. In my experience upgrading from django 1.6 to 1.7 is a bigger change than python 2 to 3
You mean exactly like Django's progressive deprecation and evolution that you're complaining about in your parent post?
Then, they released a first 3.x compatible LTS with Django 1.8. Then they released 1.9, compatible with 3.4 and 3.5.
They then release 1.10. And they are releasing 1.11 soon as an LTS, which they previously announced would be the last in the 1.x branch and the last to support Python 2. It will be supported for AT LEAST THREE YEARS after its released.
Good lord. If the deprecation and evolution gets any more progressive, it'll compete with darwinism. And yet, alanfranzoni complains about it. And YOU COMPLAIN ABOUT IT elsewhere in the thread, saying they're "screwing their userbase" and "leaving their users in the dust".
Don't you think you're being a little fricking entitled? This is an open source project and they're doing quite literally everything right.
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.
And others are bickering for the opposite opinion, so?
Did someone die and gave you authority on what others should think about Python 2 vs 3 transition?
>It is very hard not to notice your comments if one frequents this site.
I guess tolerating the presence of a counter opinion is hard. That said, it's a open discussion, and the comments are not directed at you in any way. Maybe skip them if they upset you?
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 me wrong, I'm no Python 3 hater. In fact, I have some projects in Python 3 and I would leave Python 2 if I could. But I, like many people, have to code stuff that has dependencies on Python 2, and the way they have handled the update bothers us for no good reason. In fact, the whole schism fiasco is making me use less Python and more Java, where my stone-age code still runs, lately.
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.
That's how trademarks are supposed to work; they must go after anyone using without permission or they lose it.
People are complaining about Python 3 being named Python because some code breaks under it. That would be hell.
Some things that are very useful are backported to 2, but others are just too much work.
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
Ultimately, they are the ones who maintain, care for Python and have grown the community to its current size. I totally respect their decision. Even if py3 was complete useless, I would just stop using python, not complain about how they are not doing things the way I like it.
The Python ecosystem would have been better served if they killed support for Python 2 much earlier, so that we can avoid wasting time on this tired debate, and more time writing useful code
Where's the benefit in doing that?
I am also almost 100% certain that if scientific programmers leave Python, the language will stall, and the current 3.x pushers are dangerously looking a gift horse in the mouth. This is particularly true given that Go is rapidly eating Python's lunch in all non-science use cases.
This sounds like such similar sour grapes to the systemd escapades. Huge initial outroar as certain things happened, followed by a gradual diminishing, then [mostly] acceptance.
This is what is happening with Python 3 and a smaller, doom-and-gloom subset of the userbase. Most of us are thankful that Python is striving to improve, and that we continue to pay nothing to use it. The alarmists are far more noisy than those that are happily continuing to build stuff.
Python will remain massively used in the sciences. It's simple, easy to learn, expressive, and has an excellent ecosystem of modules (which now mostly work on Python 3).
And yes Python will likely continue massively to be used in the sciences, 3 bears like me notwithstanding, so it would be good if the current stewards would actually recognize the fact that this is their core base of users and please could they focus on them instead of the web people who are much more fickle and moving already.
Ahhh, I see what's going on now. You may be vastly underestimating the size of variety of the Python userbase. This is one of the absolute most popular languages on the planet. Your science subset is but one of many. And it's not even the biggest if we're talking sheer user counts.
Python must be steered for the good of the majority of the userbase. Not just for vegabook. The fact that you described them as "useless" to me just speaks to someone being impatient and dismissive of a ton of excellent work by the contributors. These changes weren't made just for the hell of it. Particularly the Unicode example that you gave above.
If you want help understanding the rationale behind some of these changes, feel free to ask here. Someone with more familiarity will chime in and help clear up the confusion or angst.
Lol. Before Numpy and friends even existed, Python was used mostly by "the web people" and sysadmins. Scientists are one of a number of Python constituencies, and not even the best-paying nor most visible one.
Only here we don't have mere service scripts, but millions of lines of code people have written in perfectly fine 2.x Python.
And also here we don't have any significant uptake -- Python 2.x is still over 60% of what's used (according to PyPi stats and everything we've seen), and that's after 6+ years that Python 3 had its chances.
As pointed out by others, those PyPi stats are super off. Better to look at what's going on out in the community and with the most popular packages (like Django).
I'm not sure why you expect GPU from the python itself though. That's completely up to libraries and they can exist for either 2.x or 3.x. Was there ever a CPython GPU related project?
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.
I attended this talk, and it was really great. PyPi is pursuing software transactional memory, which is massively difficult to implement. The Gilectomy approach is much more community oriented, and focuses on the transition.
Put a bit differently: it's easy to remove the GIL safely, it just incurs a non-trivial performance penalty and breaks C extensions, so the Gilectomy effort is around a combination of removing or avoiding that penalty if you're not multi-threading, and smoothly transitioning C extensions. After that talk, removing the GIL looks inevitable.
That Unicode "cruft" is especially appreciated by the rest of the world that exists outside of the US. Python 2's approach to bytes and encoding is naive and horrible for 2017.
I'm outside of the US and Python 2 has worked wonderfully for ages. Its unicode support is good. You work with strings as unicode, then at I/O boundaries (and exceptions) you convert to bytes. What specifically do you find "naive and horrible" about its bytes and encodings?
Python 3 can use less memory for unicode strings (a cool optimization introduced in py3.3, IIRC), and it did away with the "narrow/wide build" distinction (same release). That's about the only every-day advantage I can think of. But I suspect that's too technical, or do you mean that?
It shouldn't take 8 years to understand this issue, and I'm positive you do understand it because you're an intelligent person, so please don't troll about it.
See what I did there?
toyg, I found your comment unbearably rude, condescending and arrogant, and downvoted it for that reason.
Confused your terminology? With static typing, the compiler will warn you, not the runtime.
Regardless, the difference is that in practice, file-handling boundary calls don't need to be as flexible as internal interfaces, and it's obviously much more difficult to figure out what The Right Thing To Do is in the latter case (or whether there is a Right Thing at all, in a lot of cases). How many times do you need to change the encoding you use for writing files? How many times do you change an internal class or type? They are totally different ballgames.
> I found your comment unbearably rude, condescending and arrogant
Apologies, but after 8 years and countless hours of bickering on this point, patience can wear really, really thin.
Yes, Python 3 is an improvement over Python 2. I like Python 3. No, Python 2's unicode support was fine, contrary to OP's claim.
But those for whom the majority of input is ASCII can often get away with broken code (that e.g. writes out Latin-1 JSON) for a while. And then they get input with a word like "naïve", and oh look, all hell breaks loose.
Python 3 solves this problem by making every transition problem explicit, requiring the developer to stop and think what they're doing when going from byte representation to strings, and vice versa.
"Explicit is better than implicit."
Besides speed, I never seen any good argument that would make me start a new project on 2.7, rather than the latest v3 release. I get that there was a series of data science libraries that wasn't supported initially, but seems to have been solved at this point. So I really do see why people continue to hate Python 3.
I'm not going to argue that the transition couldn't have been handled more smoothly, the period of broken libraries and terrible performance was a little too long.
That's because you start "new projects". Some of us have 10+ years of codebases to maintain, and we don't care for Python 3 features...
While I do believe that your point is still valid, one also have to accept that Python 2 will be a legacy platform at some point. In the long run I don't view that as much different than people complaining about Visual Basic 6 being deprecated.
Most of those years library support was non-existent or lacking. And still today the majority uses Python 2.x (Pypi stats).
So it's not like the migration was some great success since the start, and all those years were just wasted by some minority not migrating.
In the end, it's not a discussion on HN or what the "BDFL" says about an official EOL that will settle the matter, but actual adoption in the field. But in addition to the low adoption rate, we've even seen people leave Python for Go and Node/JS.
The fact that you personally weren't particularly affected by the problems in 2 doesn't mean the problems weren't serious.
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.