
Python 3 Is Winning Library Developer Support - brettcannon
https://blogs.msdn.microsoft.com/pythonengineering/2016/03/08/python-3-is-winning/
======
toyg
Windows could be the first platform to ship Python3 without having ever
shipped python2. Total clean slate, perfect opportunity, they could sell it as
MS "aligning with the cloud" and offer something special -- if I could start
and provision a Windows cloud instance from any python3 repl without having to
bother with devops tool (Vagrant, Packer, Ansible and whatnot), I would switch
tomorrow.

~~~
deadowl
Better handling of Unicode is inevitably how Python3 kills Python2. Also it's
a good reason to have not supported Python2.

Aside from Unicode, I don't like some of the other changes. The overkill on
the "one obvious way" bugs me in particular, e.g. the removal of reduce as a
core function.

The existence of "one obvious way" isn't set in stone. It depends on context,
and it's like the language developers didn't realize that when making their
decision.

~~~
Veedrac
Moving reduce into functools was more than justified: almost nobody liked it,
most people disliked it and if you really want to use if for whatever reason
an import is hardly difficult. The decision was made _because_ of the context,
not in disregard to it.

~~~
lmm
Who disliked it? I used it all the time. Was there any survey or similar?

~~~
Vaskivo
Guido disliked it. And he's the BDFL.

~~~
Veedrac
That's not quite a fair reduction; if it was just down to Guido map would be
displaced too, or even gone.

------
username223
It still blows my mind how badly the Python and Perl developers misunderstood
their languages' roles. Many developers viewed them as Unix infrastructure
like C, sed, and awk: a stable foundation upon which to build long-lasting
programs. But the core devs got bored and decided to either break most things
for very minor improvements (Python), or break everything to provide all
things to all people (Perl).

The Perl folks eventually admitted that version 6 was a separate language;
we'll see how that turns out. The Python ones can't make the same move, since
version 3 offers no major benefits/changes over version 2, so they simply have
to continue the beatings until... everyone moves to version 3. What a colossal
waste of time!

~~~
rckclmbr
> But the core devs got bored and decided to either break most things for very
> minor improvements

I think asyncio in python3.4 and async/await keywords in python3.5 is a
gamechanger. It's hardly a minor improvement

~~~
kec
Well 1) it took us 5 years to get those features, 3.0 just broke shit and ran
slowly for no discernible benefit to the end user.

And 2) I know of no reason those features couldn't be implemented in Python2
other than "we don't want to, because otherwise few people will _ever_ upgrade
to 3"

~~~
rat87
Was upgrading even recommended before 3.3?

~~~
kec
That doesn't actually help the "py3k was a good idea" argument. 3.3 came out 4
years after 3.0. 4 years to become a reasonable choice is kind of pathetic,
especially given the fact that python2 was put into bugfix-only mode 2 years
after the 3.0 release

------
mindcrime
Is anybody surprised by this? Everybody knew the transition was going to take
a long time, and that it would be a gradual process. It may be that it's
actually been even slower and more gradual than people expected, but by and
large everything seems to be proceeding nicely.

~~~
godzillabrennus
I don't think anyone expected a lengthy transition at the onset of the version
3 release. It's taken a long time and the 2.X releases that have come along
since have helped make the transition easier by showing developers some of the
benefits from version 3 releases.

~~~
EliAndrewC
I was on the "Python 3000" mailing list while it was being planned, and the
prevailing attitude seemed to be "it'll probably take 5 years before the
community moves to Python 3". (That's paraphrased and not a direct quote,
though I saw people say that sort of thing almost word for word a few times.)

This was optimistic, but at least we see that the community is indeed
gradually moving to Python 3, even if it's taking a few more years.

~~~
brettcannon
Technically the goal was a majority of new projects started using Python 3 in
5 years. Regardless, everyone knew it would take several years to reach a
point like this.

~~~
philipov
I switched from Perl to Python at version 3.4, and while it might be popular
for people already invested in Python 2 to downplay the syntactic
improvements, they were a big deal in convincing me to switch to Python as my
go-to infrastructure language.

------
afarrell
Ubuntu 16.04 LTS is planned to have only python3 installed by default

~~~
iso-8859-1
here is the bug
[https://blueprints.launchpad.net/ubuntu/+spec/foundations-x-...](https://blueprints.launchpad.net/ubuntu/+spec/foundations-
x-python3-only)

------
rcarmo
Well, I'd be happier if Pypy 3 were faster. As it is, I can get pretty decent
speedups with 4.0 (2.7.x) but not for python3 code in my use cases...

~~~
mangeletti
If Python Software Foundation would create a serious initiative to double (or
more) the speed of cPython, specifically for Python 3.5+, I'd donate at least
$100, and I'm sure there are a vast many other individuals (and companies)
that would donate as well. In the meantime, my Python-related donations go to
Django.

I think that speed can't be treated like a niche feature (e.g., via PyPy,
Cython, etc.) any longer; not with tools like Go out there.

~~~
rufugee
I wonder why Dropbox is focusing Pyston
([https://github.com/dropbox/pyston](https://github.com/dropbox/pyston)) only
on 2.7 atm. With PyPy supporting 2.7 very well, it'd seem a greater benefit to
the community to target 3.

That said, I'm sure there are specific things Dropbox needs to solve for 2.7
which PyPy doesn't do.

~~~
gsnedders
Pyston has a goal of full C-API compatibility, unlike PyPy. Dropbox are almost
certainly not trying to create the greatest benefit for the community, but
rather the greatest benefit for themselves, and they have huge amounts of
Python 2 code in production. As such, Python 2.7 with full C-API compatibility
makes sense for them to focus on.

~~~
mangeletti
Nothing wrong with self interest, especially when it directly benefits the
community in any way, big or small.

------
declnz
Interesting. Whilst it is slightly embarrassing how long it's taken, recently
I feel that Python 3 conversion is gaining critical mass, and I now hope /
expect these adoption lines to go non-linear in the coming year or so...

------
cdnsteve
Who is this Microsoft? Loving this new community involvement.

------
buovjaga
The 360 angle: [http://py3readiness.org/](http://py3readiness.org/)

~~~
levemi
fabric is that lone holdout that went against all conventional wisdom and
decided on a complete rewrite when a small few simple changes would have been
enough. fabric's developer has made promises over the last few years for their
rewrite to be beta ready and it's nowhere yet.

I say that with all the appreciation in the world for the work that went into
original fabric, which is a wonderful tool. Criticism may be harsh but it's
not inaccurate. What's amazing is that the forks to bring fabric to python3
haven't really caught on and I think that's partly because fabric is something
you do not use inside your application. It's used in deploy and configuration
scripts. It being python 2 hasn't been a problem for most people since most
distros and platforms ship with python 2 support. It's just that the people
who want to stop writing python 2 for everything including their deploy
scripts who are the most vocal and it's not a big enough group.

The fabric dev basically has until platforms start to abandon python 2, and
who knows when that will be, so maybe they have forever for their great
rewrite.

~~~
tclancy
Fabric is superseded by Invoke
([https://github.com/pyinvoke/invoke](https://github.com/pyinvoke/invoke)),
from the same developer. So other than that . . .

~~~
levemi
> Warning...While fully usable, Invoke is still pre-1.0 software and has no
> backwards compatibility guarantees until the 1.0 release occurs! Please make
> sure to read the changelog carefully anytime you upgrade!

And if I recall, it's only half of fabric's feature set.

------
ihuman
To add to this article, here is the Python 3 Wall of Superpowers. It is a list
of the most popular packages on PyPI, and shows if they support Python 3.

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

------
KaiserPro
meh, there isn't (still) any reason to really jump onboard python 3, 2.7 is
_good enough_ for me

the only real selling point is that strings are unicode by default. Unless I'm
missing something python 3 just doesn't really seem to be worth the effort,
yet.

Can someone enlighten me?

~~~
dalke
A lot of people still program in Fortran 77.

There's no reason you can't be part of the equivalent population for Python.

~~~
dagw
_A lot of people still program in Fortran 77_

Very few people still program in 77 and only if they really have to. Everybody
who has a choice has moved on to at least Fortran 90 and you won't find
anybody seriously arguing that Fortran 90 isn't a massive improvement over 77.

~~~
dalke
They weren't saying that in 1993. At least, not as I recall from the time. It
took a while for that consensus to build.

I believe that many of not most Python 3.5 users consider it a massive
improvement over Python 2.7. My examples come from the core developers, so is
highly suspect to bias.

~~~
dagw
I recently decided to make an effort and use python 3.5 for a couple of new
projects and I've so far found zero things that I consider a practical
improvement over doing the same thing in 2.7. Now it's obviously not worse
than 2.7, but saying that the new thing is just not worse than the old thing
is hardly a great selling point.

~~~
Cyph0n
Oh come on. The language level async support in 3.5 is reason enough to switch
imo, not to mention type hinting.

~~~
dagw
Language level async will probably be a reason to switch once there is a bit
more support for it and I have a project that really needs it. Same with type
hinting, once the tools and libraries are there it might be useful. But as of
today and the work I do (mainly data analysis and modelling making heavy use
of numpy/scipy and friends) I have yet to find anything in 3.5 that in itself
would be a reason for me to switch.

------
BuckRogers
It will have taken 8 years for Python3 supporting __uploads __to have outpaced
Python2. If that 's not lack of enthusiasm, I don't know what is. This is
really a pitiful display.

It's not a surprise though. This all stems back to the original reasons why
Python3 was a bad idea. Some things to keep in mind regarding Python2/3.

\- Python3 is pure technical churn, nothing there is true technical
innovation. They simply mixed the pot to their liking. Unicode is supported in
Python2.

\- It is slower than Python2 for most people. Though there are crafty
arguments out there that it's a wash. It's really not.

\- CPython3 was adopted to benefit the core development team, to make it
easier to maintain. Not the community on the whole. The community has paid the
price by doing a lot of unnecessary ports.

\- CPython3 was deliberately created to not support Python2 code even though
modern VMs can easily support this. The CLR is a great example. They did it
this way for their good, not for the community.

\- In most things in life, you'd always want to be using the latest supported
version. That isn't the case here. It may still effectively "fail" with a
permanent split. This migration is not even close to being completely in the
books and won't be for another 10 to 20 years. So why punish yourself moving
before it's in your best interests. The syntactic differences are so slight,
it's extremely easy to switch to Python3 if it ever truly reaches Python's
momentum (this article does not convey momentum holistically, that includes
package downloads and the majority of employers using 3).

\- Related to the bullet above, almost all job opportunities are still
Python2.

\- The ecosystem can't keep up, PyPy is still only production-ready on
Python2. Python 3.2 support is essentially experimental by comparison.

\- Many changes and additions are being made and they aren't being vetted by
the larger community. No significant userbase for Python3 has created this
situation. Mistakes are being made and no one is around to speak up because
the core devs don't care.

\- Python3 is feature-soup. There is now a new 4th and possibly 5th string
formatting method in 3.6 incoming. Really jumped the shark on that one. See
Mark Lutz's great insight on this topic and more.[0]

\- Downloads are still dramatically in Python2's favor, to this day. Judging
from downloads, there's a ~10% community userate of Python3.

\- The bullet above means that the Python3 packages you do use are far less
vetted and tested than the Python2 equivalent.

\- CPython3 was slopped together. The initial 3.0 release was mostly pure
Python in effort to get it out the door. Many parts of the standard library
that are written in C are slower than the modules used in the CPython 2.7
counterpart, to this day. It was not and is not being tested. The users are
not there to test it either.

\- Community trust has been broken, I'm not sure anyone really believes
another big break isn't incoming regardless of statements to the contrary. The
core dev team is going to do what they want and you're going to like it,
period.

\- Python3 zealots have done a lot of harm by not accepting valid criticism,
and aggressively attacking those who do what is in their best interests (which
we should all do, this should not just apply to the CPython core devs), and
continue using Python2 all these years. Watch for downvotes instead of
countering my points.

\- The 2020 date is a just a big political stunt and scare tactic. Code will
continue working after 2020. As noted, it works better in CPython2 and PyPy
today, and likely will in 2021 as well.

\- Python3 lives off of and is pushed by PSF propaganda. No way around it as
there is no innovation involved. Which is what should determine if new
technologies are adopted or not.

\- Usually when people make mistakes, such as Python3's existence, or the
inability to mix Python2 and 3 code in the same VM- they go back and fix them.
That has not happened with CPython3.

\- Even back in 2014 projects such as Pyston from GvR's employer (Dropbox),
were Python(2)-only. It's still Python2 today, which says it all.

All that said about this trainwreck, I'm in favor of getting back to a single
major version of Python for the community. I'm using 3.5 for a single project
myself but I will still plainly state the truth about the Python3 transition.
It was a bad idea, for all the wrong reasons to benefit a rogue band of
developers who believe since you aren't paying them- you as a community do not
matter and should shutup and get to porting.

I love Python but will eagerly embrace Pythonic language alternatives as more
are released. In particular, I'd love to see a Pythonic Erlang variety similar
to Elixir. Or better yet, just a concise, minimum featured version of Python
without all the extra. Picking 1 string formatting method would suffice, the
basics but done well, stable in feature-set like Go and compiled. Something
similar to a Pythonic Lua would suit me and would be the ideal case for a
Python-reboot. Making it a subset of Python2 would make a lot of sense.

Lesson learned and bottom line is that we should overthrow all BDFLs.

[0][http://learning-python.com/books/python-
changes-2014-plus.ht...](http://learning-python.com/books/python-
changes-2014-plus.html)

~~~
rjurney
Would you consider putting your ideas for Python in my Python 4 project on
github?
[https://github.com/rjurney/python4](https://github.com/rjurney/python4)

~~~
BuckRogers
\- Call it PythonCore instead of Python4. Avoids any possible trademark issues
if it does take off, and the semblance between "four" and "core" rings nicely.

\- PythonCore should be just what we the people need, rather than feature soup
with community promise of compatibility like Go. Python2 subset, removing some
extraneous features and removing the std lib.

\- One could start with CPython 2.7.11 and disable all the keyword features
that weren't wanted or strictly needed. I would go about this by asking the
guys behind PyCoders Weekly would send out a survey asking Python developers a
series of questions on what to keep. Combined with surveying a few recognized
Python experts (not Guido). I think at this point in Python history, we know
what we definitely do and do not need.

\- As well, ditching the standard library and putting it all as strictly
package imports. Forcing it all to compete with other solutions on equal
footing but still being there for reference. That would be the basis of the
new 'PythonCore' and give people something they could rely on as a stable,
unchanging featureset for years. New features would be imported, extremely
rarely added to the core.

\- This would be declared as a continuation of Python2. Though clearly not
supporting all existing code, it may require little more than changing your
string formatting in the end.

\- After this, two main efforts would be involved. Initially ditching the
CPython 2.7.11 base implementation for a compiled alternative. Nuitka would be
an interesting solution to look really hard at, PythonCore may be the language
that Nuitka has been waiting for to really shine. This shouldn't take long to
get up and running considering Nuitka is already working and should compile a
strict Python2 subset just as well as it does the entire language today.

\- The second and I think most important, and time consuming effort would be
in duplicating the success of NPM for PythonCore. This would make or break it.

\- You could do the same for a Python3 subset but I think what many, many
folks (and businesses) want is some option to continue on Python2. This would
be a way forward that could be supported relatively easily as the supported
core would always remain small. But it still retains the POSIX oriented nature
that we all love about Python rather than the Microsoft/JVM/CLR unicode by
default decision with Python3. I like many Python2 users, stick to retro OSes
without a text / binary distinction. If it was good enough for Kernigan and
Richie, it was good enough for Joe Ossanna, it was good enough for Robert
Pike. Well, it's good enough for me.

\- In sum, influences would be Lua, Nuitka, CPython2.7, NPM.

------
stared
Plots using second since epoch as the x axis... nope. (I mean, if I do it then
it is for internal plots only and still I am feeling lazy.)

------
dsil
I really like the showing-his-work, via ipython/jupyter notebooks.
Unfortunately it's behind an azureml login so it can't be directly linked.

~~~
chupapuma
If you want to link to the Jupyter Notebook, you should be able to share the
notebook in the gallery.
[http://aka.ms/py3winningnb](http://aka.ms/py3winningnb) or, if you want a
less nice url,
[https://gallery.cortanaanalytics.com/Notebook/95a0e835f88b43...](https://gallery.cortanaanalytics.com/Notebook/95a0e835f88b439ab0537c7b8e6daac5)

------
inanutshellus
I program in python 2 because that's where /usr/bin/python takes me to. ;-)

~~~
ChrisArgyle
Believe it or not, you don't even have to change your workflow to try out
python 3. If you're on a Red Hat/Ubuntu-based system just add a '3' to
everything (python3, pip3, pdb3, etc)

edit: added relevant platforms

~~~
inanutshellus
I've been bitten by Poe's Law[1], despite the winky. Blast!

Edit: Really though, it's a problem of apathy. I'm supposed to _care_ about
python 3? Why? When I type "python" on the command line (and everyone else
that doesn't care, which is most every "filthy casual", right?), I--and
everyone else with a default install of Ubuntu and CentOS/RedHat--gets python
2. Fix that, and overnight you'll have massive python 3 uptake.

In fact, you're suggesting I set myself up to be stuck with the problem Maven
is in, which is that everyone has an "m2" repository even though they're onto
Maven 3. I'm supposed to hardcode "3" into everything? C'mon.

[1]
[https://en.wikipedia.org/wiki/Poe's_law](https://en.wikipedia.org/wiki/Poe's_law)

~~~
brettcannon
I believe both Ubuntu and Fedora have/are dropping Python 2 from the default
install this year.

------
jedberg
Sadly I'm stuck using Python 2.7 until Amazon Lambda supports Python 3.

~~~
abrookewood
Yes, just found this out today. Rather annoying! I've logged a ticket about it
for what it's worth ... even cited this article.

------
markonen
Python 3 : Python 2 :: IPv6 : IPv4

~~~
collinmanderson
IPv6 came out 10 years before PY3, though I have more hope for PY3.

------
ksec
And No love for Ruby. Sigh

/Rant

------
MrZongle2
FTA: "In 3 months, Python 3 will be better supported than Python 2."

This just seems to validate my choice to stick with Python 2 up until now.

~~~
lmm
If you're an application developer rather than a library developer then yeah
that may well have been the correct decision. But if you intend to maintain
your application for more than 3 months then it's time to switch to Python 3
now.

~~~
MrZongle2
_" But if you intend to maintain your application for more than 3 months then
it's time to switch to Python 3 now."_

No disagreement there. But I'm surprised at the downvotes I've received.

------
rjurney
I recently started Python 4, which will be backwards compatible with 2.7.
Submit your ideas as issues today!

[https://github.com/rjurney/python4](https://github.com/rjurney/python4)

~~~
maxerickson
Beware that Python is a trademarked name.

I honestly can't tell if you are joking or think that using "Python 4" as the
name of such a thing is a good idea (no way will the Python Software
Foundation let you use their trademark, so if you are serious, you are just
setting yourself up for hassles).

~~~
rjurney
Thanks for the feedback, I'll look into it.

I think Python 4 is a good name because most Python users feel that Python 3
was a misstep, and never plan to move to Python 3.

~~~
collinmanderson
Yeah, "Python 4" sounds _less_ compatible with 2.7, not _more_ compatible. I
like the "TwentyEight" name, or how about "Two4Evr". :)

