So, after a poor evolution strategy that lead the Python world to be split in two and forces maintainers to offer two versions for the same library, and upstream maintainers to offer support for two different python versions, the same is happening for Django!
I speculate that the latest Django 1.x will remain used - and possibly the most used - for a lot, lot of time.
I disagree, I think Django dropping support for 2 will actually push more open source projects to do the same. This will create the momentum and incentive necessary to nudge people over the edge and upgrade.
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.
Agreed. We've got a ~100k line Django project and I'm fairly confident it won't be more than a day or so of work to migrate. The only thing keeping us on 2.x is our dependencies most of which already have Python 3 support so it's really just a matter of us upgrading dependencies.
- 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.
> forces [...] to offer two versions [...] the same is happening for Django!
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.
No core Python dev will support Python 2 after EOL. Some corps may continue to do so sure, just like there are Java 1.4 codebases still in production. I will work on a Java 1.4 codebase if you are prepared to pay for my accrued personal obsolesce as well. If your Java 1.4 job is the last job I'll do it has to pay for the next 15 years lost income as well. The same will go for Python 2.
Sincerely, the only "poor evolution strategy" from Python developer team was that they continued to support Python 2 long after its initial expire date after announcing the Python 3 roadmap.
The support should have been cut a long time ago and now we wouldn't be having this discussion.
I think whatever goodies Django 2.x will have, they'll be backported to 1.x by somebody.
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.
Yep. I've done 1.6->1.7->1.8->1.9 at my current workplace and 1.6->1.7 with Django migrations was the biggest one by a long way. The documentation for upgrades is great too.
Please, don't tell me how "Python3 is good" - I know everything. I just still don't approve the way the transition was made - if we got to Python 3 through progressive deprecation and evolution via python 2.8 and 2.9, we wouldn't be where we are now.
The Django project has added Python 3 compatibility in Django 1.5 as experimental. It remained experimental in 1.6. It became supported in 1.7. They announced around that time that Django 2.0 would only support Python 3.
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.
I couldn't agree more. This transition and their release management in general has been handled excellently for years. Anyone complaining here is quite literally whining.
You talk as if Python 3 were a dialect of Lisp. It's still Python, looks like Python and feels like Python. In fact, I think most of my Python 3 code runs on Python 2.
You talk as if the switch doesn't look like a bunch of arbitrary decisions made on the appearance of purity. If more of an attempt had been made a maintaining compatibility, there wouldn't be nearly as much fight. Python 3 becomes a bit uncanny valley for me when I try to code in it and I tend to use a different language as there less of an internal code switch, especially as I still have to maintain large numbers of python2 code.
The truth is, it's Python. I'm not looking for a great language, I'm looking for language that'll help me get work done... quickly and not give me a migraine if I have to come back to it (Perl). The 3 changes are just big enough to catch me (and every other Python programmer I've worked with) so that I can't just program, which tends to push me towards keeping it in 2.7 or switching to another language, where the similarities don't exist to pull me into bad habits. The whole mess really sours me on the language that made me love programming again.
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
Making the transition more "progressive" would just decrease the incentive of developers and companies to move even more.
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.
What would you do in 2.8, 2.9 that 2.6, 2.7 didn't achieve? 3.0 was released almost at the same time as 2.6, and together with 2.7 they got a lot of backported 3.x functionality. Sounds like what you're asking for.
Pretty much the only people that are working towards splitting the community are people like you, who spread FUD and sprinkle snide, bitter and wrong remarks across threads.
Notice how I made a pragmatic observation (that it's already a fork), which one might agree or disagree with, and you went for name-calling about FUD, snide, bitter, "people like you", etc.
That's, like I said, my general observation from reading like a dozen comments from you just on this item. You're literally bickering on about this in pretty much every Python-related item on HN. It is very hard not to notice your comments if one frequents this site. I stand by my comment above.
>You're literally bickering on about this in pretty much every Python-related item on HN.
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.
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.
The Python Software Foundation are the people who have earned the reputation that the name "Python" has - they're the ones who get to use it. And their judgement is that Python 3 is the future of Python. A fork under a different name can earn its own reputation based on the technical merits of its decisions.
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.
You already have Python 2. This is a continuation of it that is simply closer in semantic to Python 3. How could it be bad if apart from the Unicode semantics the two versions became equivalent?
Py2 or PyClassic. They don't own those, and they sure could link to python to py2/PyClassic for people who want to install it. They don't own the letters py.
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 development etc with asyncio whatever, but for me all I get from 3 is Unicode and xrange cruft that simply complicates my code for zero benefit. Personally am hoping that something new emerges that will take over from Python altogether as the default in data science, or that some big entity will sponsor a fork of 2.7 to shutdown this ridiculous "eol" dictatorship.
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.
So what you're saying is that Python 3 changed some small stuff that you see no benefits in, but moved a year ago, and you're now on Py 3.4. And because of that small no-benefit update, you want to move to completely different language that will start with: no scientific libraries, no community, and will likely require rewrite of everything you work with?
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 going down a path where I don't see a long term future for it in my domain, and therefore, I am looking elsewhere already.
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.
> 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 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).
>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.
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.
PyPI stats are massively inflated by automated deployments, and anyway even them show a clear rising trend for 3. Also, 3.4+ (from 2014) is a very different beast from 3.0, and it's probably not a coincidence that porting significantly accelerated after its release (about 3 years ago).
With numerous libraries phasing out support for 2.x in current or upcoming versions, I think we actually do have significant uptake.
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).
Except that personally I see the benefit of Systemd every time I boot my linux computer. It just works, fast, and clean. I don't partake in the philosophical arguments. I just want it to work. Py3 by contrast, simply throws cruft curveballs at me. No tangible benefit. This is not a systemd-style issue.
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.
> 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.
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 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?
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.
Yeah, you are a bit condescending here. Part of the topic was multicore. If you're interested in actually cutting down the data transfers without resorting to explicit shared memory, GIL and threads are very much on topic. Whether it's an overblown issue depends specifically on your workload and reasons why you're still using python if you care about multicore.
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.
To me, unicode alone was worth the switch. I will go to great length to avoid the hell that is unicode in Python 2.
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.
If you don't care about the Python 3 features, then don't migrate. I suspect that the issue is that you want at least some of the features, but the cost of moving 10+ years of Python 2 to Python 3 just aren't worth the benefits of those new 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.
Python 3.0 was released in 2008. Python 2 will EOL in 2020. You've had about 9 years to start the transition to 3.0, and you still have 3 more years before EOL. A 12-year upgrade window sounds pretty reasonable.
>You've had about 9 years to start the transition to 3.0, and you still have 3 more years before EOL.
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.
I'm not seeing signs of these kinds of widespread issues out in the wild. The popularity of the language has continued to increase, and numerous warts and flaws were wiped out in Python 3.
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?
This has been explained over and over. Those boundaries in python2 are very easy to get wrong and the runtime will not warn you, which means you won't know about them until some crap data comes down the wire and code chokes or (worse) silently corrupts data. In py3 you are forced to explicitly Do The Right Thing, so entire classes of bugs are just Not Possible.
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.
"With dynamic typing, the runtime will not warn you, which means you won't know until some crap data comes and your code chokes. With static typing, you are forced to explicitly Do The Right Thing, so entire classes of bugs are just Not Possible."
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.
It's actually easier for people outside of US, who are forced to deal with languages that require Unicode to work properly. If you screw up somewhere, you notice right away.
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.
For what it's worth, as someone who ha been working with Python for 11 years, Python 3 is a huge improvement over Python 2 and is certainly very popular with my peers.
The fact that you personally weren't particularly affected by the problems in 2 doesn't mean the problems weren't serious.
I speculate that the latest Django 1.x will remain used - and possibly the most used - for a lot, lot of time.