
Python 2.8? - bootload
https://lwn.net/Articles/711061
======
placebo
Back when python 3 was introduced and after learning of breaking backward
compatibility my first thought was, "good luck with that"...

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.

~~~
ProblemFactory
> So, years later, the only thing I'm surprised at is that Python 3 actually
> caught on to the extent it did.

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.

~~~
saurik
The fact that you could choose to be that careful with Unicode in Python 2.7,
though, is important to not forget: if the only change was that now you had to
be, then code could have easily migrated and worked on both. This was the
story of Ruby 1.9, which was, compared to Python 3, a cakewalk.

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).

------
frunzales
The amount of trolling in that thread is incredible. I don't understand why an
average Joe needs to contradict Guido on trademark matters.

~~~
scrollaway
Because some people are hateful by nature and see Guido as Satan incarnate for
"hating Python 2".

And no, I'm not exaggerating, you just need to look at the comments:

[https://github.com/naftaliharris/placeholder/issues/47#issue...](https://github.com/naftaliharris/placeholder/issues/47#issuecomment-266464920)

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_

~~~
ktRolster
_Treat your FOSS maintainers with some human decency._

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.

~~~
sametmax
Except most FOSS maintainers don't have glory or money. They do it for the
project. While politicians rarely do it for the country. In all my life, I've
never heard one I deeply respect that was elected. I see many FOSS maintainers
I respect that are in charge.

------
freyir
I suspect there's a sudden push for "Python 2.8" from some of the 2.x holdouts
because it's becoming increasingly obvious that the wider community is
coalescing around 3.x. I feel a bit sorry for people stuck on large Python 2
projects and who can't make the jump, but there's a very vocal minority in
this group that wants the rest of the world to be held back along with them.

~~~
oliwarner
For those people genuinely "stuck" I can certainly understand wanting to
prolong the life of 2.7 past 2020. It keeps legacy products secure and working
without having to retool them onto 3.x, which really _is_ a big job. Why not.
The core python team is unhappy keeping it on life support but why couldn't
somebody else?

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.

------
daveguy
I'm glad Guido considers this a toy. Anyone interested in helping out the
github repo is here:

[https://github.com/naftaliharris/placeholder](https://github.com/naftaliharris/placeholder)

~~~
didibus
He's right though. Backporting features will be hard, and it looks like the
wrong move. If you wanted to fork just fork, and evolve python 2.7 on its own.
Why try to create an inferior python 3?

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.

~~~
unixhero
The problem is some of the massive python modules that cannot be ported from
2.7 to 3 .x

~~~
viraptor
Which ones specifically? Many massive ones that held out for a long time are
either done or in the process of porting. (twisted, openstack, almost all web
frameworks, etc.)

PS. [https://python3wos.appspot.com/](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.

~~~
unixhero
Yes I was thinking about twisted

------
copx
The fork should be called "Lython" as in Legacy Python.

------
gaelow
NO. No way. It's the second time I see this here. The answer is not a hybrid
that is neither 2.7 nor 3.0 compliant. That's just a third, useless standard.
Let's just please stick to one standard, preferably the most current from the
official ones and start porting/rewriting whatever we need until we need the
old one no more. Please.

------
ram_rar
I am afraid that, the python community has messed up 2.x => 3.X transition.
Until 3.3, there seemed no incentive to port your codebase to Python 3.X.

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.

~~~
Cyph0n
Transitioning from Python to Go isn't as easy as you make it out to be. Good
luck finding solid alternatives to the likes of Numpy, scikit-learn, Pandas,
SQLAlchemy, BeautifulSoup, Flask etc. Oh, and not to mention the community
surrounding these and other popular Python libraries.

~~~
tyfon
All of them work in python 3.x too. Well. I'm not sure about flask, it's not
one i use personally.

~~~
notamy
I've been using flask with python 3.6; it seems to be working fine.

------
vaibhavsagar
This is wonderful! The next time anyone asks why Python 3 is better, I'll just
link them to this project's README.

------
douche
The 2.X => 3.X transition really appears to have been bungled here, which is a
shame. I really liked Python before I got deeply into the .Net world, but it
has become less than enticing with this fragmentation. Meanwhile other
languages seem to have taken up the vanguard position, which leaves Python in
kind of an awkward position, between the new hotness and the tried-and-true
enterprisey ecosystems

~~~
copx
>The 2.X => 3.X transition really appears to have been bungled here, which is
a shame.

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.

~~~
otabdeveloper
No, the problem is that Python 3 sucked, and still sucks.

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.

~~~
scrollaway
There's plenty of problems with Python 3 and the transition, none of them are
that "Python 3 sucks".

You know that, of course, otherwise you'd have provided an actual claim rather
than a generic complaint.

------
jononor
Someone make a Python 3 which can load Python 2 code, to allow for gradual
migration.

