
Python 3 is killing Python - sebg
https://medium.com/@deliciousrobots/5d2ad703365d/
======
zanny
I don't think people are used to backwards compatibility breaks in languages.
Though in some ways, that means you have a different language.

In reality, Python 3 is to Python 2 what Ruby is to Python 2 - different. They
aren't the same language, you could have named Python 3 Anaconda (just because
Cobra is already taken, I know it is a prepackaged library bundle for Python
already) and its function would be clearer.

But you also can't tell people writing free software "no, you have to stop
doing what you want, and do what _I_ want" unless you are willing to negotiate
how much that will cost you. And maybe they wouldn't do it for any price. You
could get other developers to extend it on your doll as well.

But the developers of Python collectively said "unicode is important enough to
make a backwards incompatible leap". They are never painless. OpenGL is a
great example, with how the version 3 line was rife with attempts to
depreciate the fixed function legacy cruft, and even today few developers
properly differentiate compatibility and core profiles. _That_ is a major
version break too.

But if you don't like it, you can make your own. The fact there _isn 't_ a
major popular python2 extension project trying to backport functionality
unofficially that has gained traction should say what the popular consensus on
python 3 is.

If you need python2 libraries, use python2. There is really no shame in doing
it. Even when the official project depreciates the maintenance of 2.7
_someone_ will pick it up, because there will be for decades, at least, and
probably for eternity, python 2 software running somewhere and the maintainers
think keeping python 2 working is less effort than porting their stack to 3.

~~~
PythonicAlpha
The problem is not only Unicode.

If it only where for unicode, the problem would not so big. But they seemed
not to bother at all about backwards compatibility at all in the first Py3
version. Later, they did try to change some things, that unnecessarily(!!)
blocked adoption, but many projects already decided to ignore Py3.

I guess, you don't mean what you said in the last paragraph? Was it just a
joke?

Unless you can replace __all __libraries that exist only as Python 2 version,
you can not move -- you can use zero Python 3. That is a huge problem to real
projects -- of course, if you only have some University (educational) -
projects, all is fine and you can play around as you like.

Also there is the problem, that it is not trivial to have Python2+3 on the
same installation. Most Linux distros still run with Py2.

~~~
ghostwriter
> Also there is the problem, that it is not trivial to have Python2+3 on the
> same installation. Most Linux distros still run with Py2. >

Actually, it's trivial nowadays with projects like pyenv. You can even have
different python versions in a per-project-directory basis.

Check out the installation guide
([https://github.com/yyuu/pyenv#installation](https://github.com/yyuu/pyenv#installation))
and a commands reference
([https://github.com/yyuu/pyenv/blob/master/COMMANDS.md](https://github.com/yyuu/pyenv/blob/master/COMMANDS.md))

There's also an extension that provides virtualenv integration -
[https://github.com/yyuu/pyenv-virtualenv](https://github.com/yyuu/pyenv-
virtualenv)

~~~
PythonicAlpha
Thanks, that looks interesting. I will note it for the time, I have the
problem.

~~~
pekk
This is the same problem addressed by the ancient, universally known tool
named virtualenv. How are you delivering pronouncements about the
unsuitability of Python 3 when you don't have solid knowledge of how things
are done in Python?

~~~
PythonicAlpha
I did not "deliver pronouncements about the unsuitability of Python 3". I did
only say, that it is not trivial to have both versions on one installation.

And who are you, something like the "Python purity police"?

I will ask you something, that you did not work with till now -- and when you
give a wrong or incomplete answer, I will also say "how dare you"!

------
naner
Within the few industries I've had a peek at (not hip startups or web
companies) this doesn't appear to be that big of a problem. Companies that
rely on Python 2 code in the background seem to be sticking with Python 2
without any noticeable penalty or incentive to change. And places that have
their core business wrapped up in python seem to be gradually making the
transition OK. It's not without cost but you do what you have to do...

This sort of thing isn't uncommon... I see old perl installs behind production
software, ancient versions of RedHat, Oracle, etc. and I deal with mostly
technology centric companies so that's likely just the tip of the iceberg. Old
software doesn't really go away.

------
doe88
I learned Python in 2004 (circa Python 2.3) and since developed several years
mainly in Python, but somewhere along this path I lost almost all my excitment
and joy for this language. I used to dream in Python, now I find it cumbersome
and to me Python 3 was an unnecessary pain and I also know some people are
afraid to say it explicitly because you want to look as someone who remain on
top of your game by being able to cope with new things, but knowing how to
deal with Python 2/3 doesn't mean it was a good move. I'm now just happy to
not have to develop in Python anymore.

~~~
Scramblejams
What did you move to?

~~~
Peaker
Not the same guy, but I moved to Haskell. Not due to Python 3, but because
I've realized that to get the awesome features Python has, I don't have to
give up the safety and performance I thought I had to.

------
baq
yadda yadda. i'm happily developing in 3.4 and the improved exceptions alone
make it worth it. the pain is pretty much limited to 3rd party libraries
(getting better every day, though not nearly fast enough, true) and people not
understanding bytes vs text (incidentally, mostly native english speakers.)

~~~
mrweasel
Agreed, Python 3 is in almost all aspects better and I really prefer 3 over 2.
Most of the bigger 3rd libraries are already ported, at least all the ones I
care about.

Numpy seems to be the biggest issue for most, but I guess it must be in some
special area, I never found a need for it doing web development.

The unicode support removes so many of our problems, although I can understand
the issues strings vs. bytes that a some people run into.

~~~
neals
So what is this strings vs bytes thing all about?

~~~
mrweasel
I think Armin Ronacher has the best overview:
[http://lucumr.pocoo.org/2014/1/5/unicode-
in-2-and-3/](http://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/)

But it's basicly Python three killing of the byte-string and ignoring the fact
that in some cases it actually makes sense to work with string that are
specifically not unicode, rather than resorting to have a bytes type instead.

~~~
pekk
I don't see how it is coherent to ask for a string that is not unicode, and
not bytes. What is it?

~~~
dragonwriter
A string encoded in some non-unicode encoding.

Not everything in the world is unicode (or unicode compatible the way, say,
US-ASCII is.)

------
jammycakes
I've never really understood these claims that Python 3 only offers minor
improvements over Python 2. Some of the improvements in Python 3 are quite
significant: the example that comes to my mind first and foremost is that
strings are now Unicode by default. These days you should really be using
UTF-8 as your default encoding right across the board (the only exception
being when you have to interact with legacy systems), and any language that
doesn't make it so is quite frankly a deal-breaker as far as I'm concerned.

~~~
postfuturist
Python 2 has unicode literals and utf-8 available if you declare them at the
top of your file. You don't need Python 3 for that.

~~~
jammycakes
Yes, but it's not the default and it does require special considerations. This
means that code written by inexperienced developers (or even more experienced
developers who aren't familiar with the ins and outs of Unicode and
internationalisation etc) will be more likely to behave incorrectly when
presented with anything in a foreign language.

~~~
zo1
If they have difficulty grasping those concepts, then they shouldn't be
working with them. They should rather stick to plain ascii/latin-1 and leave
the fancy things to people that know what they're doing. Python3 in this case
wouldn't be a silver bullet to make them magically work with unicode better.

~~~
jammycakes
_Nobody_ should be sticking to plain ascii/latin-1, and certainly not
inexperienced developers. The only valid reason for using anything other than
UTF-8 these days is that you are interacting with a legacy system that doesn't
support it.

Unicode isn't a "fancy thing" that is best left to "people that know what
they're doing." It's the difference between displaying a name such as Siån
correctly and as a bunch of hieroglyphics.

Besides, even for experienced developers who know what they're doing, if
you're imposing any form of ceremony or special considerations around using
Unicode, you're increasing the risk of bugs and mistakes.

That's why I say Unicode should be made the default. It's legacy encodings
such as Latin-1 that should be treated on a need-to-know basis.

------
yk
I think the problem of Python 3 is, that it is too close to Python 2. Learning
Python for the first time is really fun, compared to other languages. There is
almost always a interesting technique that does exactly what you need and
usually great tutorials. But switching from Python 2 to Python 3 is quite
frustrating, it is just different enough that one can not rely on intuition,
but it is similar enough to lure one into using intuition. With the added
frustration that all the errors would just not be there in Python 2. So
assuming that I will not get payed to become a Python 3 expert, I will just
write Python 2 and pick up another language at some time in the future.

~~~
u124556
Mostly, what you need to become a "Python 3 expert" is learning the Python 2
__future__ module. Use it for a while, then the switch will be seamless,
intuition-wise.

------
akerl_
In my experience, the lack of support by common libraries is not nearly as bad
as the author claims:

[http://python3wos.appspot.com/](http://python3wos.appspot.com/)

~~~
the_mitsuhiko
All my libraries run on Python 3 but I would recommend nobody to use them on
that Python version if they can also use them on 2.x. They have better unicode
support on 2.x and there are more 2.x users thus less bugs in 2.x specific
code. Aside from that, the ecosystem for other libraries is bigger.

~~~
akerl_
The point you raise regarding the impact userbase-size has on the library is
very important in the Python2/3 split. It's similar to the divide that multi-
architecture releases have to deal with, where less common platforms are more
likely to have long-lived bugs just because the userbase is smaller and less
likely to find and identify them.

If, as the author of an impressive collection of Python libraries, you had to
make a rough estimate of when your Python 3 userbase will reach critical mass,
such that they have a reasonable shot at finding those bugs and getting them
fixed, how far into the future do you think we're looking?

~~~
the_mitsuhiko
Last time I was looking less than 5% of my users which was two months ago (up
from 3% two years ago or so) used Python 3 at least going by download stats.
But Python 3 support takes way more than 50% of my time :-/

------
dj-wonk
Re: "There are other solutions, but reviving Python 2 is so obviously the
correct thing to do, that other solutions are not worth mentioning."

I don't even know how to respond to such "logic".

------
pgtruesdell
I completely agree. Since the release of Python 3, I've attempted to get
familiar with Python and I always have this dilemma.

Which version do I learn first?

On a first, ignorant, glance learning Python 3 makes sense because it's the
way of the future. Although, the more you learn, you slowly figure out that
they're not that different; but, they're communities and supporting libraries
are in two separate camps. It's like there's a cold war mentality of people
who can't or won't port/migrate to 3 and the Python 3 crowd that looks upon
the former with disgust and disdain. There's clearly a huge divide and it's
uncomfortable and confusing for new folks to learn and get involved.

Now we're about 6 years since the first Python 3 release and I've never gotten
involved with Python beyond a few days of tinkering. I've moved on, and based
on my experience, people who are newcomers to programming are walking right by
without a second thought. This coupled with the developers that are jumping
ship, isn't good news for Python. They need a course change, and they need to
make it quickly.

Just my $0.02.

------
ginko
Forking Python 2 would be a terrible idea. Especially since 2.7 keeps on being
supported anyway.

Python 3 is the way to go in the long run.

------
7952
Even without python 3, it has become an increasingly complicated ecosystem. I
run python 2.x on windows for scientific uses and find incompatibility to be a
common problem. I need separate 32 bit and 64 bit versions which use different
dlls that may or may not be in several possible locations and use incompatible
libraries. Trying to run pypy or python 3 would be just to complicated.

Python is not a single ecosystem any more. We need separate distributions that
can be self contained.

~~~
peatmoss
I've been told the Anaconda distribution
([https://store.continuum.io/cshop/anaconda/](https://store.continuum.io/cshop/anaconda/))
of Python can ease some of the pain there. The fact that I have to direct you
to a "store" to download it does give me pause, however, even if the
distribution is actually free.

~~~
travisoliphant
The link to the "non-store" download page which we tell everyone about is:
[http://continuum.io/downloads](http://continuum.io/downloads).

Yes, we are a company and do sell things, but our commitment to open source is
backed by many, many years of significant contributions to the community. We
give as much away as we can, and sell to those who need more.

While you certainly buy more from us, Anaconda itself will always be free as
long as we can continue to make it.

~~~
peatmoss
Thank you for that. And thank you for your contributions. My point about the
store was more aesthetic. If you are ideological about the openness of your
tool chain (and I start edging that way the closer things get to science),
then the "exit through the gift shop" is mildly off-putting. I say mildly,
because it still doesn't prevent me from recommending it over other
alternatives. I also understand that your paid products add value (and in the
case of MKL, aren't yours to open-sourcify anyway).

The non-store link definitely feels more open-sourcey. I'll be sure to send
people that way. Again, I didn't want to imply that you all were bad open
source stewards.

------
upofadown
This seems a bit overdramatic. Yes, the attempt to do a version number hijack
by a influential set of developers is annoying but there is no reason that it
can't be just ignored. Python 2.7 doesn't need new features. It is still
wildly useful without them. It is perhaps even more useful without them...

You can't deprecate a computer language. Such a thing exists independently of
implementations.

------
tlogan
I feel the pain :(

The problem is that there is a misconception that python libraries needs to be
"maintained" and if they are not maintained they should not be used. However,
many long-tail libraries really do not need to be "maintained": the code is
well tested, works, and it has no security implications. Some of these
libraries are just clever algorithms or re-engineering of some obscure
protocol or format.

I guess this is one more reason that java is still the safest choice :( Sad.

------
cot6mur3
Decent read - it further helped me appreciate the position from which Python 2
devs require certain non-trivial, non-ported libs are coming.

That said, as a mostly Python 3 developer, PEP 404, to which he links,
provides much insight and justification for ending at 2.7. In brief, the
changes all seem to me to be efforts to make Python more 'Pythonic' (i.e.
TOOWTDI).

PEP 404 2 -> 3 reasoning: [http://legacy.python.org/dev/peps/pep-0404/#and-
now-for-some...](http://legacy.python.org/dev/peps/pep-0404/#and-now-for-
something-completely-different)

TOOWTDI:
[https://wiki.python.org/moin/TOOWTDI](https://wiki.python.org/moin/TOOWTDI)

------
Eyas
I'm curious what the lesson here is. A lot of the changes in Python 3, such as
the byte format of strings, seem to be a good thing--just something that
breaks compatibility.

Is the lesson never to bother fixing a major flaw in your software/language
after it has been widely used/available?

~~~
sqrt17
There are two precedents to look at: Java and Perl.

Perl grew from merely useful to your-favorite-whiz-bang by being a decent
language and growing a large collection of third-party modules. Then Larry
Wall decided Perl5 wasn't fun anymore (also because of wart accumulation) and
declared Perl6 to be The Future(tm). Years later, we have some remaining stuff
that's running in Perl5, and also some enthusiasts that use Rakudo and Parrot
in an attempt to reach the Shangri-La of Perl 6. But, in many important
respects, Perl is an ex-parrot and Parrot won't change that all that much.

Now for Java. Java started out as a slow and ugly cousin of C++ that ran alot
slower and gave you the worst of having a bad compiler and a stupid bytecode
interpreter. As Java gained traction, Sun and others (e.g. IBM, Apache)
proceeded to fix all the warts in a backward-compatible way. Java 1.2 finally
had decent collections. Java 1.5 adopted Philip Wadler's proposal for generics
through type erasure. Newer Java releases added some sorely-missing utility
functions that you'd take for granted in other languages, such as converting
between an array and an ArrayList, or splitting a string.

Somewhere in-between, we got servlets, JSP, JDBC, Hibernate, JAXB, a fast
compiler. It's not so bad, even though the language still bugs me sometimes.

What's in store for Python? Similarly to Perl, and differently to Java,
Python2 has byte-strings, and just when people where coming to grips that
there are some things for which str is a good fit and others where you want to
use unicode, you got the "unicode as default" in Python3. A conservative
approach would be to extend the language and libraries so that it becomes
natural to use unicode objects in the places where you're dealing with text,
and keep the functionality that bytestrings have around so that the old code
is still working. Python3 did not choose the conservative approach - indeed
the goal was to do all the compatibility-breaking things that were needed,
upfront.

Despite that fact, there is hope that Python will not undergo the Parrot-to-
ex-Parrot transition that Perl underwent. The Python core is already there,
and many important libraries - including the numpy/Cython etc. toolsuite, and
different web frameworks, are actively trying to find the remaining issues.

So, as a summary: A lot of the changes in Python 3, such as renaming the old
strings into bytestrings and removing a lot of their functionality, are well-
intentioned but have considerable problems. It definitely gets harder to fix
major flaws in a language that is widely used, and blackmailing the users by
declaring the "not as fun" old version of your language dead should not be
done lightly if you don't want to become the next Perl.

~~~
chromatic
_Perl is an ex-parrot and Parrot won 't change that all that much._

It's worse than that. Rakudo developers declared Parrot deprecated (in favor
of a new VM which had yet to be written). That, of course, drove off all of
the Parrot developers--see the decline in commits in March 2011:

[https://www.ohloh.net/p/parrot/commits/summary](https://www.ohloh.net/p/parrot/commits/summary)

If Rakudo ever reaches a point of stable equilibrium where it's reasonable to
think about creating libraries for it, P6 still faces an adoption cycle that's
more difficult than that of Python 3. There's no plan for P6 to replace Perl
(partly to avoid that adoption pain, for one, and partly because P6 has taken
so long, there wouldn't be any Perl users remaining unless P6 had publicly
changed its strategy).

Python's transition hasn't been quick or easy, but it's gone much, much better
than the P6 fiasco.

~~~
kamaal
I won't comment on Parrot, because I know nothing of Parrot or Perl 6
internals. But from what I hear and read on the internet, the new VM, Moar VM
is doing pretty good as a parrot replacement.

 _P6 still faces an adoption cycle that 's more difficult than that of Python
3._

I don't see how, especially when p5 developers are saying they will continue
to support p5 long after p6 is released. And p6 is such a far drift from p5
that you can almost call it a new language. And no one if their right frame of
mind will re write all p5 software in p6.

So it will be p6 for any new projects and p5 supported all along.

 _There 's no plan for P6 to replace Perl (partly to avoid that adoption pain,
for one, and partly because P6 has taken so long, there wouldn't be any Perl
users remaining unless P6 had publicly changed its strategy)._

From what I read(Again, I have no personal contributions or sources and I rely
on what I read or hear on the internet) in
[http://jnthn.net/papers/2014-fosdem-
perl6-today.pdf](http://jnthn.net/papers/2014-fosdem-perl6-today.pdf) [pdf]
rakudo is very close to spec completeness. And bulk of the effort currently is
implementing last bits of spec and improving the speed.

 _Python 's transition hasn't been quick or easy, but it's gone much, much
better than the P6 fiasco._

Python is hardly comparable with Perl 6. They just changed a print statement
and iterators in Python 3. Perl 6 is a very different story completely
altogether.

~~~
raiph
__TL;DR __Imo, for at least the next year, the P6 project needs to encourage
contribution by folk who enjoy creating an entire system and discourage use by
folk who just want to get stuff done.

\----

I've loosely followed P6 since 2000; daily read the log of the central hub of
P6 activity -- the IRC channel #perl6 -- for the last 3 years; and summarized
it daily for the last 2 years.

I am concerned about folk getting the wrong impression about Rakudo's
readiness for general use by mainstream programmers that just want to get
stuff done.

I started using the following disclaimer a year ago and I think it still sets
expectations appropriately:

Perl 6 is not remotely as usable and useful as Perl 5; it has dozens of users,
not millions; it is 100-1000x slower than Perl 5 for a lot of stuff; the P6
documentation is immature and incomplete; the spec has not reached 6.0.0; the
Rakudo compiler has not fully implemented what's already in the spec; most of
the concurrency and parallel implementation has only just begun; P6 can not
currently use CPAN modules; Perl 6 has syntax and semantics that are not
backwards compatible with Perl 5; Perl 6 culture is -Ofun which some think is
incompatible with getting things done; some folk think that Perl 6 code looks
like line noise... In summary, there are infinitely many things wrong with P6.

\----

> From what I read ... rakudo is very close to spec completeness ...
> implementing last bits of spec and improving the speed

Ignore implementation (Rakudo) for a moment.

The _spec_ isn't complete.

There's very recent talk of producing "a list of big ticket items remaining"
for "hitting 6.0" and "a tri-color marking of the spec" showing "Implemented
in Rakudo, not implemented but we agree we really should for 6.0, deferred to
6.*".

~~~
kamaal
I think only some one far detached from reality would expect, a Perl 5 like
ecosystem ready on the day of Perl 6.0.0 release. And most people don't need
many Perl 6 esoteric features either. So I guess your "a list of big ticket
items remaining" hopefully won't be "a big list of ticket items remaining".

Besides I was of an opinion even after the 6.0.0 release the spec won't be
complete. Spec will never be complete. Spec is a backwards compatible changing
piece of document which the implementation tries to catch up with. The stable
releases of the implementation are production releases.

Lastly you could just say. Esoteric features a, b, c, d are left for next 6.*
releases. While release a 6.0.0 release is cut after with whatever you decide
from that list earlier. The world is in no hurry to use the esoteric features
anyway.

Either way, I wish you guys all the very best. And hope to soon see a closure
soon on this.

~~~
raiph
> I think only some one far detached from reality would expect, a Perl 5 like
> ecosystem ready on the day of Perl 6.0.0 release.

I think it's still plausible that someone (it'll have to be one or more
serious P5 guts hackers) will soon start implementing something like
diakopter's plan for P5+XS interop. (That's the plan for having P6 code
calling P5 code and back again, including XS modules on CPAN.) If that works
out well, a 6.0 release could be viewed as including all of the P5 ecosystem
or, conversely, as an experimental part of P5.

But perhaps I'm far detached from reality.

I certainly wouldn't expect the project to wait for such interop. If 6.0 has
to ship without support for P5+XS modules, so be it.

> So I guess your "a list of big ticket items remaining" hopefully won't be "a
> big list of ticket items remaining". > Besides I was of an opinion even
> after the 6.0.0 release the spec won't be complete.

It sounds like the plan is to mark particular bits (paragraphs?) as either 6.0
or post 6.0 and associated spectests will determine whether or not Rakudo is
compliant.

For more of the discussion see
[http://irclog.perlgeek.de/perl6/2014-05-23#i_8767026](http://irclog.perlgeek.de/perl6/2014-05-23#i_8767026)

> Esoteric features a, b, c, d are left for next 6.* releases.

I don't know about the esoteric aspect being the decider, but yes, I'm
assuming the basic idea will be to defer as much as is reasonable.

> Either way, I wish you guys all the very best. And hope to soon see a
> closure soon on this.
    
    
        { "this" }
    

Maybe not what you're after?

Seriously, while I hope for a 6.0 spec this year I think there's about zero
chance of a 6.0 Rakudo this year. And unless a few dozen more contributors
turn up maybe not in 2015 either.

~~~
kamaal
Thanks, for the link.

But you are talking of another 2+ years. That's a lot of time in software.

~~~
raiph
Sure.

I wish it could be quicker and I hope it will.

In the meantime I contribute as best I can.

------
PythonicAlpha
I remember, when Py3 first came out, everything was incompatible --
unnecessary incompatibilities like the u" notation for Unicode string literals
that was dropped. Unnecessary incompatibilities in the C-extension-module
implementation layer. And so on. The list of incompatibilities was just huge.

Later several of them where dropped, like the string literal trouble ... But
than the trouble was already done. Many extension modules where not lifted to
the new version, since the overhead was to big.

I think, many more projects would have adopted Py3, if more extension modules
would support it.

The huge library of extension modules was always the strength of Python. Now
we have many projects still running on Py2, because Py3 did ignore this
strength.

------
theseoafs
The author didn't really give any concrete examples. What kinds of major
Python libraries still need to be ported over to Python3?

~~~
sitkack
The author is talking about long tail libraries, not major ones. The thousands
of libs on PyPi that are still on 2.x

~~~
akerl_
Except most of the more obscure libraries I find are either abandoned projects
or were written to support the author's needs and don't fit the generic use
case.

To note, that's not a Python-specific issue: it's the nature of any language
ecosystem where modules can be made by anyone, and I'm not even sure it's a
bad thing: I've learned a lot, even from libraries that I didn't end up using
for whatever reason.

I think it's dangerous to imagine Python or any language as something where
all the libraries you need always exist, and thus any time you have to write
your own libraries it's a failure. Embrace the library ecosystem: you're going
to eventually find something that isn't covered, which is when you write a
library and participate.

Disclaimer: I know open sourcing code isn't always possible, and that
time/project constraints can impact how much backend code a developer can
write. But if we dismiss Python 3 just because some of the more obscure
libraries aren't ported, I wonder how we ever picked up Python 2 originally.

~~~
sitkack
I am not dismissing Python3 outright and neither is the OP. But rewriting
millions of lines of code to satisfy an artificially imposed requirement is
probably not a good idea even if the libraries are "abandoned"

Python3 ranks high on the list of engineering failures. Python3 itself is
fine, Python3 the deployment and migration is a disaster.

~~~
akerl_
The abandoned libraries I find end up needed to be mostly rewritten, even if I
were to use them on Python 2.

------
wiz21
Maybe there are thousands of unported stuff but frankly, how much of that is
useful/ready for production use (production=paid software with bug translating
to losses) ? I'm perfectly fine with Pyside, SQLAlchemy, ReportLab and a bunch
of few other things. I don't need the n-th lib with half baked, unicode
broken, poor error handling, non portable, Disney-tested stuff. So, if only
10% of the libs have moved and those are the production quality stuff, then
fine. What a useless article.

~~~
jlarocco
Have to agree here.

Most of the libraries I'd actually trust for more than a one off script are
already ported or have plans for porting.

I wouldn't trust a lot of the unported libraries in a serious Python 2
project, anyway.

------
pacofvf
Python (2) is heavily used in the finance industry, a industry that still uses
cobol and fortran, they will never move on to python3

~~~
KMag
> they will never move on to python3

Sure they'll move on to python3, in the same way they moved on to C++, Scala,
and VHDL.

Perhaps they will never abandon Python 2, like they haven't abandoned Cobol
and Fortran. However, that doesn't mean they won't move on to Python 3.

------
fennecfoxen
Sounds like Perl 6, all busy stifling Perl 5. (Which has sort of shaken itself
out of somnambulance with a similar technique.)

~~~
orkoden
Python 3 is doing a lot better than Perl 6.

~~~
sitkack
Even if Python 3 emerges as this great thing, it could still stunt the Python
ecosystem. Python (the thing) is distinct from Python programming, there are
plenty of amazing languages that no one uses.

------
mkonecny
This was a horrible article. With plenty of jumping to conclusions. I agree
that Python 3 divided the community., but this article grossly over-
exaggerates.

------
WoodenChair
Basically the author's argument boils down to "if you have a long list of
dependencies, some of them will not be available in Python 3 and therefore
your program will be hard to port." That is true, but it also reflects an all
too pervasive problem in modern open source software development - an over
reliance on third party dependencies - "dependency hell." We've all seen a gem
file or requirements.txt that is absolutely absurd. People need to stop
relying on little libraries created by some random dude 3 years ago and never
updated for their production code.

~~~
ludamad
And how do you feel about forking and maintaining those libraries? I think the
'little' here means 'arcane'. If the code serves a solid purpose, and you
understand it enough to maintain it, it should be better than writing it
yourself.

------
guilloche
I had both versions installed(arch linux). I wanted to remove one of them long
time ago, but there are lots of dependencies on python2 in arch (gdb mercurial
etc.).

python3 do break many of 3rd-party scripts I am using, so I make /bin/python
symlinks to python2. Each python3 update will break these scripts and I needed
to symlink python again. So, finally, I removed python3 completely.

These 3d-party python codes are well maintained, but the authors seems not to
bother to port them to python3 if python2 is still available.

------
tebeka
People forget that doing backward breaking changes take a while. Python 3 was
released at the end of 2008, 2 years _after_ Java 6. How many systems you know
still run on Java 5?

~~~
postfuturist
Java 6 did not break backward compatibility (code written for Java 5 generally
runs fine on Java 6).

~~~
alphabetam
Code written for Java 2 runs fine on Java 8, with extremely limited
exceptions. Java, just as Windows, is used too much in enteprise apps to lose
backward compatibility.

------
drdeadringer
I began my python coding in both 2 and 3. I eventually dropped 2 and stayed
with 3, because I didn't need any of the "still haven't made it to 3"
libraries for what I was doing.

Part of me feels like I'm living in the future, waiting around for everyone
else to get over it. I then have to remind myself about the nature of change
over large groups of people, and wonder what else I could be missing.

------
Istof
Over the years I have noticed that lots of software's newer version are worst
then previous versions.... luckily with open source software like Python,
developers can keep updating/forking older versions. I wish that I could still
be using gmail beta for example.

------
camus2
It's true that Python 2 and 3 are entire different languages.They have the
same basics but once you dig a little,they are very different.

As hard as it is for people like me who use 2.X a lot,Python secured its
survival with 3.I wish the transition would have been smoother though.

------
johanneskanybal
minor benefits: hardly. unicode alone is a big deal. problem with 3d party
libraries: sure, for now. good solution suggested: no, not really.

------
chinpokomon
I find the conclusion, that there should be a Python 2.8 which maintains
backwards compatibility and which adopts some of the newer 3.x language
features, to be misguided and uninformed.

What the author of this article is suggesting is precisely what Python 2.7 is.
Python 2.6 was the last 2.x release that brought new features to the language.
2.7 is only about back porting 3.x language features as a "temporary" stop gap
measure until 3.x reaches maturity, both as a language and through 3rd party
library support.

It is precisely this kind of thinking that is going to "kill Python," not the
language itself.

------
arthursilva
Python 2 will still be there, why spend energy back-porting stuff when you
could just keep using python2 or improve python3 or even porting to python3
(it's actually not that hard).

------
naithemilkman
How about checking out the wall formerly known as shame.

[http://python3wos.appspot.com/](http://python3wos.appspot.com/)

------
mattdeboard
Python 3 simply suffers from a very serious image problem that was caused by
the objectively terrible launch of the first couple of versions.

------
tremols
I loved python and honestly when I started hearing that there should be a
"pythonic way of doing things" my bullshit alert ringed as this was pretty
much against the freedom that made the language appealing in first place. It
started going downhill from there and I am affraid there is no coming back.

------
erikb
Strange that no comment I've read here so far mentions marketing. Of course
it's mostly marketing. It's a human problem, not a technical one. Think about
how many bad programming decisions were shipped by the big IT industry just
with a beautiful presentation?

------
mundanevoice
The best would be to have Kickstarter to port the remaining major libraries to
Python3. Python3 is obviously much better than Python2 and helps in writing
cleaner and better code. Progress is made looking towards the future and by
continuous improvements.

~~~
pekk
Let's define "major".

~~~
mundanevoice
Good point. It could be the libraries which are used by a lot of people like
boto. There could be many more.

------
echaozh
I am not very familiar with pyc, but IMHO, if pycs compiled from both versions
are compatible, the migration process should not be that painful. Syntax can
change, but given stable ABI, librariescan be shared without pain. Why has no
one done that?

------
Sir_Cmpwn
OT: Did Medium make some changes recently? The scrolling performance is
_dreadful_.

------
brownbat
I take issue with the assumption that everything was perfectly compatible
before the jump to 3.

I kept running into random incompatibility issues even within 2, like Pai Mei
(a reverse engineering tool) only working on 2.4.

------
chhantyal
While author seems to believe all gloom and doom, look at this graph
[http://py3readiness.org/](http://py3readiness.org/)

Python 3 support is getting better everyday.

------
yiedyie
Python 3 is not killing Python just competes for resources. Python 2 will be
around until 2019 and a lot of things can happen in 5 years.

~~~
rffn
IMHO Python 2 is one of the big, important languages of computing history with
a large enough user and code base which makes them go nowhere, no matter what
a committee decides. I would put Cobol, C, Perl, Java, Fortran in the same
league. Like 'em or not - they are here to stay.

~~~
Sanddancer
And they've all had incompatible changes over the years. There's C89 code that
won't compile under C99, a good amount of Perl4 code won't compile under
Perl5, let alone 6, Fortran 66 code that won't compile under more modern
versions of fortran, etc. This myth that this is a python thing is complete
hogwash if you look at the history of programming languages.

~~~
im3w1l
But a C99 program can link against a C89 library, right?

~~~
rffn
Maybe, maybe not.

Could be that the header file is not compatible with C99 either. This seems to
me rather likely. Also it might be that the ABI changed in a way that the C89.
This depends on platform and tool chain.

There is a large amount of code which is compatible. It is easy though to get
an example which isn't.

------
u124556
What popular third party libraries don't have a port and don't have one
planned for the next 5 years python 2 will be around?

------
readme
Python 3 isn't killing python. If you're one of the guys who isn't going to
jump ship, siyonora. In a few years your python skills are going to be legacy
only. Django, Pyramid, SQLAlchemy, all support it... it's time for web
developers to switch.

So what if an obscure library on PyPI doesn't? Port it already. Or don't use
it? The other day I removed a 'module' from my project by substituting 1-2
lines for "import lxml" and etree.fromstring(xml) instead...

~~~
the_mitsuhiko
> In a few years your python skills are going to be legacy only.

If the trend continues then in a few years your python skills are going to be
legacy only and you will program Go or something.

------
anaran
What is that photo from wikipedia? Anyone know that theme?

~~~
anaran
Ah, screenshot in firefox command line, google search, and here is the answer:

[http://www.wikiart.org/en/gustave-dore/the-inferno-
canto-13-...](http://www.wikiart.org/en/gustave-dore/the-inferno-canto-13-1)

------
JimmaDaRustla
Since when was python 2 "deprecated"? I chuckled.

~~~
anthony_d
Well, if you go to python.org and ask "Should I use Python 2 or 3?" the
prominent answer is:

Short version: Python 2.x is legacy, Python 3.x is the present and future of
the language

That's very close to what deprecated means.

~~~
pdonis
If "deprecated" allows a very long period of time before actual end-of-life,
yes; Python 2.7's current scheduled EOL date is 2020:

[http://legacy.python.org/dev/peps/pep-0373/](http://legacy.python.org/dev/peps/pep-0373/)

~~~
sp332
Yes, it does. If something is deprecated, that just means people are advised
not to depend on it, usually because it's going away.
[https://en.wikipedia.org/wiki/Deprecation](https://en.wikipedia.org/wiki/Deprecation)
It doesn't mean that it has already gone away.

------
illumen
I doubt the lazy people who haven't moved to python3 will ever do a decent
port of python 2. Python3 has been out for over six years now, with warning
before that.

I'd much rather bet on the python developers who are shipping software. All
major python libraries have been ported to python 3, many of them for years.
There's 4799 packages registered on pypi as supporting python 3.

Python is becoming less popular? The author provided no evidence at all.
Downloads of python3 from python.org are higher than python 2, and have been
for a while now. Job websites show python having more postings than 2 years
ago.

Not much has changed in python 3? What rubbish. You just have to look at the
thousands of commits, and change lists. Python 3.4 has generic functions to do
single dispatch matching on type. You can statically type check python now
(see pysonar2, pylint, and pycharm for example). Not only as pypy made a major
breakthrough with performant STM based concurrency(no threads), but threading
has been improved in python 3 too. There is the new asyncio library for really
elegant async, which go along with great generator improvements(yield from).
We have CFFI for simpler FFI. Lambdas are kept simple for readability, as
functions are preferred.

I'm just going to stop here... many of his statements are just insane. Like
this one: "You might as well ask someone to port their entire codebase to
Ruby". Um, yeah... porting a codebase to python 3 from python 2 would take
more time than porting it to an entire other language. What complete nonsense!

Edit: the post isn't from Microsoft, so fixing it so it isn't misleading.
There was a link to a Microsoft person on the top right of the page, which
seemed to indicate he was the author. Instead it was just someone promoting
the page. Oops/sorry!

~~~
postfuturist
I'm the author. I've never worked at Microsoft (where did you get that?). I'm
a Linux guy.

The "lazy people" you refer to is 98% of the Python community.

Python 3 didn't "gain" static type checking. You can (and I do) run pylint
against Python 2 code which is just static analysis, not full type checking.
The situation here has not changed between Python 2 and 3.

Python is glue code. You write a small piece of Python to tie together
external libraries. Moving a smallish piece of Python code from Python 2 to
Python 3 often means porting several 3rd party libraries. If you were to move
to Ruby, all you'd need to rewrite is your own code, as there are likely
already 3rd party libraries which need no porting.

~~~
akerl_
Do you have examples for these critical 3rd party libraries that haven't yet
been ported?

As I noted elsewhere in this thread, the list gets shorter every day:

[http://python3wos.appspot.com/](http://python3wos.appspot.com/)

~~~
bitL
If you are running multiple automated eCommerce companies that have their core
system written in Python 2 like I do, you'd find that boto/mws and python-
excel aren't available for Python 3 (python-excel's porting to Py3 stopped in
2011), which would prevent you from spawning new businesses on Amazon or
handling (unfortunately standard) MS Office interchange files quickly.

I actually made the decision to run on Python 2 due to unavailability of these
libraries for Python 3 about a year ago (I didn't really care about Python
before as I primarily used C++/Java/Asm/GLSL/C#/Haskell in the past) - I was
deeply shocked by what Py3 did to its own community and still have that weird
feeling that Python is slowly killing itself. I didn't want to write my own
Amazon and MS Office wrappers in Python 3 anyway and from all platforms
available Py2 seemed to have the least amount of troubles (though I had to
write some Py3 code for handling advanced TLS properly).

~~~
fat0wl
yup. I think this is the reason so much eCommerce software is Java (& I'm sure
there is a bunch of C# but that's not my thing). Java moves like a glacier but
damn is it ever stable, and for those who wish to be "cutting edge" there is
everything-under-the-sun on the JVM -- Clojure, Scala, Jython, JRuby, slimmer-
by-the-minute Java APIs. And the community is just working their lil buns off
trying to modernize this stuff while maintaining interop / backwards
compatibility.

I think the flack Java gets is for not modernizing fast enough, but I think in
a way that makes you stop and smell the roses (the roses being many years'
worth of badass JVM features and massive flexibility/reliability in software
development).

But Ruby & Python (I am an ex-Ruby guy) take this cutting edge thing wayyy too
far & end up with a community of people who can't trust them anymore cuz they
all had their damn feet shot off. Sometimes I see the rates for Ruby guys &
wonder if they're high cuz its so productive or just cuz its very niche & the
stack is shite. On principal, it's hard for me to imagine going back down that
road after experiencing the JVM (plus, I'd like to get away from web one
day...).

EDIT: Funny thing I just realized actually -- all the Ruby rates I've seen
tend to be exactly on par with a lot of FUBAR niche near-extinct Java
technologies. The only people I've seen do better than both these camps are
down & dirty Linux/Oracle/Java guys. Maybe my view is skewed but I always feel
like the rock-solid langs will live on & eventually "modernize" (though lets
be real, modernize is kindof a BS term for slim API & lots of MVC tutorials).
These other techs are at the mercy of market trends.

~~~
tetha
Java is simply becoming the next C. For a reason, in my opinion, since the
languages share quite a few traits both on the language level and the
ecosystem level. Both are fast. Both have a rock solid execution system which
sometimes feels backwards compatible to the first punch card made of rock (gcc
vs JVM). Both of them have huge communities having significant infrastructural
services and other huge code bases developed in them (linux kernel,
application servers, databases in both teams). The big improvement of java
would be a higher programmer safety.

And to be fair, neither language is the prettiest, shiniest and fanciest for
it's time, but they get the darned job done.

~~~
fat0wl
you (& bitL as well) make some fair points but I actually (maybe because I'm
newer to Java?) have quite a different experience with it. The XML setup seems
minimal now (sure it's all there but most stuff is now handled with reasonable
default configs & annotations).

Take Jax-Rs is a good example. Once you understand it you're just like "Ohhhhh
this is the same way Rails/whatever framework handles json requests but I can
add in all this non-linear logic without forcing it to play nicely within a
presumptuous design pattern". Adding many data sources & logic flows is easy.

Bottom line is that I feel like Java can never really be the next C because
fundamentally its much safer and becoming way more human readable. It toes the
line well -- you can code minimal stuff similar to the scripting languages, or
you can drop years of work/research into optimization for high-transaction
algorithms knowing that the platform won't abandon you.

(By the way, I am personally hoping for Clojure or node.js to take over the
front-end of the stack & then just using Java to do any heavy lifting that is
left over)

------
mantrax5
The author should realize that it's better for Python 3 to kill Python 2,
before Go, Ruby or some other platform kills Python.

If you don't cannibalize yourself from time to time, someone else will eat
you. Fact of life.

Or in simpler words. Stop bitching, and port that library to Python 3.

------
poink
Apparently the only measure of a programming language's worth is how many
libraries it has.

Alright, boys. Pack it in. We're all going back to C89. Don't try anything
new, because you'll never catch up.

~~~
postfuturist
"One of the great strengths of Python 2 is the long tail of 3rd party
libraries" does not imply it is the "only measure"

~~~
poink
The _only_ point made in this entire article is that Python 3 is "killing
Python" because a lot of Python 2's libraries haven't been ported.

Your quoted statement might not imply what I said, but this article damn sure
does.

------
dj-wonk
Re: "One of the great strengths of Python 2 is the long tail of 3rd party
libraries to do, well, just about anything. Python 3 doesn’t have this." Sure,
this isn't ideal, but this is open source... if you use a library, step up and
port it over. How hard is it?

~~~
neals
Yes, honest question. I've never written a line of python. How hard is it to
port 2 -> 3?

~~~
andreasvc
It's not so much that it's hard, but it's a lot of work, without tangible
benefits. On top of that, it's desirable to have a code base that is
compatible with both 2 and 3, which requires awkward workarounds.

