Python 2.8?
lwn.net
lwn.net
Wanting to create something better is not surprising. What was surprising (to me at least) is not seeing that people don't like change unless they see a really dramatic benefit to what they already have, and clearly see that the advantages to making that change far outweigh the discomfort of the process.
Most people have a really hard time changing from something they know, even if it's less than perfect. Actually, even if it sucks. Ask any marketer, salesman, social worker or psychologist and you will see this is not limited to programming languages, and beyond the psychology, change has an economic price that needs to be justified.
So, years later, the only thing I'm surprised at is that Python 3 actually caught on to the extent it did. I don't know whether to attribute this more to the quality of the language or the energy that went into promoting migration to it, but its current adoption rate to me is a mark of success when one tries to compare it with other attempts to reeducate a well established market.
Most of the migrations I have seen have been because of a stick rather than a carrot (e.g. this library we depend on is dropping py2 support). It's definitely the case that the move has only been as successful as it has because of the (relatively) unified effort of popular open source library authors to switch common dependencies.
I have been using Python 3 for 2 years now in production, and I would never want to go back to Python 2. Benefits include:
- less boilerplate. Automatic super(), no object inheritance, yield from, generalized unpacking, keyword only args, less itertools import, no need for __future__, f-srings, etc. Basically my code is shorter and faster to write.
- better error handling. This one is big. It is easier to get a bug free Python 3 program. You get exception nesting handling, finer file exception granularity, more safety nets (e.g: no more arbitrary object comparison), better error messages, absolute import by default, regular division by default, etc. As a trainer, Python 3 is so easier to teach.
- unicode is no just about u''. You have the "encoding" parameter everywhere by default. Everything default to "utf8" naturally. You don't need the # coding: monbo jumbo. There is no more "auto-casting" of bytes. English native speakers underestimate the value of this. As a European, it's invaluable to me, and it is to the rest of the world that is not using ASCII as their main alphabet.
Those are really, really great benefits. But terrible carrots. They don't sell. People want big shinny stickers with "+30% perf" which will never be of used for most projects. While those benefits, I guaranty, are stuff all project benefits from, and you feel them a lot once you get used to them.
Well, it's been over 8 years. And we've just reached the point where nearly all libraries are available in Python3, and Python3 is recommended for starting new projects.
Python3 was also a very unconventional backwards incompatible change. 90% of the incompatibility came from "you must correctly and carefully handle unicode vs bytes". All other backwards incompatible changes were trivial in comparison, almost fixable by search and replace.
And "careful handling of unicode vs bytes" was something that you already could do in Python2, and should do in Python2, but weren't forced to. If you did, then upgrade to Python3 was easy. If not, then you had a massive testing and refactoring problem on your hands.
I would not even see it as a language change, but would compare it to C and C++ compilers turning -Wall -Werror on as mandatory flags in the latest release. It would be sort of "good for the ecosystem" in the long term, but would also be a lot of effort for people with legacy codebases.
The reality here is that you are just wrong in both understanding and premise :/.
First, all these minor changes are actually extremely serious, as they made it hard to impossible to have cose which ran on both; as someone who was nowhere near an expert in Ruby, it was still easy to write code which straddled the boundary between 1.8 and 1.9. Ruby 1.9 really could be seen as a set of "warnings" on 1.8.
Second, the most serious change in Python 3 was not Unicode, it was actually the way it handled generators and iterators and lists in various contexts: this was a set of changes which broke lots of code in subtle ways and which could not be handled using your argument of search and replace (and which contributed to the awkwardness of having code running on both 2 and 3 at the same time).
And no, I'm not exaggerating, you just need to look at the comments:
https://github.com/naftaliharris/placeholder/issues/47#issue...
I read through that thread the other day and it breaks my heart to know that there are people who think like that. Honestly.
On various occasions I've reasoned (and not reasoned) with the most absurd people, there is always some way to understand where the craziest of logic comes from. But here, I'm just sad.
And I'm especially sad because I've seen similar comments on HN (even just the other day). So really, this goes out to anyone who works in tech and feels like this either about Python or about any open source project: Treat your FOSS maintainers with some human decency.
It's not the first time I say it, and every time I say it there's always some people nodding at this; "oh yes, of course, well who acts like that really?", those same people turning around a week later, flaming Lennart Poettering for whatever software du jour the guy wrote.
sighs
(no direct relation to political parties intended)
The same could be said about politicians, too......although they are easy to ridicule. It makes it hard to get good leaders when no sane person would choose to endure all the abuse a political candidate gets.
This is the kind of thing where you are appealing to a legacy user base and there's no reason to get smirky about it. Something like Twothon, Bithon (not good for obv reasons), Zweithon, and so forth would much better communicate the intent of the project IMO.
But this "2.8" is about adding 3.x language features onto 2.7, essentially declaring a brand new language standard for new development. People who want this aren't saying they don't want to upgrade, they're saying they want to stay on 2.x forever. That seems perversely stubborn to me.
I could see security fix releases be useful. Giving people more time to transition is going to benefit some projects. But in terms of feature, it does sound toyish.
Appart from that, it actually doesn't look like there's any problem here. The maintener agreed to change the name.
I don't expect this project to exist for very long unless it breaks free, but if it tries to just bring 3 features back to 2, I'm not sure it'll make sense for very long.
PS. https://python3wos.appspot.com/ now shows only few packages not marked as compatible from the most popular ones. One group (carbon, graphite, supervisor) are not libraries so they don't really affect others. The other is specific moz* libraries - and they're for Mozilla's internal testing, so nobody else should care that much.
Because you're importing big legacy python2 libraries.
I think the point is -- it will not be an inferior python 3.
It will be a python 2 with the best non-code-breaking parts of python 3. Sane byte handling + bug fixes - breaking changes.
That will make it a superior python 3.
Depends what you're working with, obviously.
For the vast majority of the actual planet, this simply isn't the case.
> Backporting features will be hard
It's actually pretty straightforward: I just find the relevant changes in the Python 3 history, and apply them to Python 2. Usually a handful of things have changed between 2 and 3, so I typically can't just pipe the diff to "git apply -3", but frankly backporting features is more tedious than difficult. If you're interested, for example, here's my recent implementation of the "nonlocal" keyword; you can see the commit messages reference the Python 3 commits: https://github.com/naftaliharris/placeholder/pull/60
> Why try to create an inferior python 3?
The ultimate goal is to build an interpreter that can run both Python 2 and 3 code. Unfortunately, there is some code that runs and has different behavior under Python 2 and Python 3 (e.g., 'print("a", "b")' ), so anyone who wants to write an interpreter that can run both kinds of code will need to decide what to do there. I decided to defer to Python 2 behavior in those cases, since most of my code is in Python 2 and I don't want to change it. :-)
That is a great goal, I fully support you.
so anyone who wants to write an interpreter that can run both kinds of code will need to decide what to do there
Even if the interpreter has to decide, "this file is python2, it will do it one way.....that file is python3, it will do it another way" that is good enough. As long as you can call functions and such between the two files.
Python 3 was released in December 2008. Python 2.7 was released in July 2010, and was given 5 years of support which was then extended to 10.
Those people who have not transitioned yet have not done so because of lack of time. They might have valid reasons for delaying, but time is not one.
In 2020? There will certainly be a business case once you get hit with an RCE in 2.7 because there will be no new security patches.
- you need to choose either bytes or str, you can't have both. And Python 2 API have many functions accepting and returning bytes while Python 3 have many ones with unicode.
- the C ABI and the byte code changed.
- built-in changed.
So you will have to choose between one behavior or the other and deal with it. This is what you do with the excellent six or Python-future libs. They let you write 2/3 compatible code, but the first thing they do is making you choose either the 2 or the 3 behavior.
With golang getting a lot of traction and compiler tools like grumpy (python -> Go), I would rather invest time to transition into golang as apposed to transition to 3.X.
Just to bring up a small counterpoint: I don't think anyone really expected the early 3.x releases to be used in production. They were, as I recall, intended primarily as proof-of-concept releases to let people start looking at what porting would involve, and to get feedback and make improvements in the 3.x series to make porting easier and production deployments nicer.
I see this as a huge red flag. Its ok, to break/experiment things until you reach 1.0. After that, the core development team must factor in the consequences of breaking backwards compatibility.
Obviously, the question is what went wrong.
Personally I think the dev team gave users too much time to switch.
The Python devs should have only given users one or two years to upgrade. Making it clear that all support for Python 2 would end after that period.
Another mistake was that when originally released Python 3 did not offer enough shiny new things to convince people that going through the pain of upgrading was worthwhile.
They made this worse by backporting features from Python 3 to Python 2, something they should have never done. Python 2 should not have gotten any new features after the release of Python 3.
Python 3 advocates like to blame the users for not upgrading, but I think that is / was simply the result of the actions of the dev team which made staying with Python 2 too comfortable and moving to Python 3 not attractive enough.
Twisting your user's arms even more painfully won't solve the problem, it will just accelerate users switching away to other languages or forks.
You know that, of course, otherwise you'd have provided an actual claim rather than a generic complaint.
This is the core issue, but you're putting cart before horse a bit: if there's not much to gain from switching, why would any reasonable person switch? And, most importantly, why is it a problem that needs solving at all?
For language devs. It's always good to learn from mistakes from the past. PHP 6 failed, then PHP stayed with 5.x and moved directly from v5 to v7 - that worked out fine.
The Python 2 to 3 is an important lesson as well. Ruby (afaik 1 to 2), dotNet 1 to 2 and 4 to dotNetCore 1, Swift 1 to 2 to 3, ... are several more cases that were rocky for developers.
As I understand it, Matz considers the upgrade strategy until now quite successful, mostly because at the same time breaking changes occurred people got things they wanted (e.g. faster VM) which encouraged them to upgrade.
Hence the "ruby 3 will be 3 times faster than ruby 2" idea, that's the carrot that should contrast people's will to not update.
Not only that, they effectively took away a lot of vital shiny old things like numpy and django. It was something like 3 years between python 3.0 and the first stable releases of numpy and django with python support. That was 3 years where python 3 was effectively useless to a large number of python developers, and you can lose a lot of momentum in 3 years. Had the core python team gotten together with the teams for numpy, scipy, django and a couple of other big name libraries and coordinated the release of python 3 with versions of all those libraries that would work with python 3, then I imagine things might have gone a lot smoother.