
Most popular Python packages now support Python 3 - simonw
http://py3readiness.org/
======
sago
Clicking around, those that don't seem to be:

1\. Obsolete. Either explicitly so (e.g. Google API) or abandoned, without
even a minor/patch release (initools, 2010) or in some cases a code commit
(e.g. pathtools, 2012) for five years or more. I suspect that they will never
be Py3, the community will just move on to alternatives.

2\. Working hard to bring support (e.g. ansible).

3\. Part of the graphite ecosystem. If the base library won't change, none of
its ecosystem will.

4\. Not on public version control / issue tracking, so who knows (e.g.
supervisord)

~~~
finnn
A brief look around the supervisor site indicates that they have public
version control and issue tracking on their github page[0] and that they have
a merged PR[1] to add python 3 testing (which appears to be passing).

[0]
[https://github.com/Supervisor/supervisor](https://github.com/Supervisor/supervisor)
[1]
[https://github.com/Supervisor/supervisor/pull/901](https://github.com/Supervisor/supervisor/pull/901)

~~~
sago
Thank you. I wonder why they don't list this in their setup.py

~~~
collinmanderson
They do. I wonder why it's not green.

[https://github.com/Supervisor/supervisor/blob/master/setup.p...](https://github.com/Supervisor/supervisor/blob/master/setup.py#L59-L64)

~~~
sago
I meant the repo and bug tracker, which is can we listed in setup.py and is
picked up by pypi.

~~~
collinmanderson
The repo has Python 3 listed in setup.py. Are you saying it isn't?

(It's not getting picked up by pypi because they haven't made a release with
the trove classifier yet.)

~~~
sago
No, setup.py doesn't list the _repo and bug tracker_ , so pypi doesn't list
the repo and bug tracker either.

~~~
collinmanderson
Ahh. I see. Thanks.

------
jasonrhaas
Yup at this point there is no reason to not use Python 3 for new projects.
What I'm finding actually is that some companies that have their codebase in
Python 2 have actually started migrating to Golang rather than Python 3,
because of the increased performance benefits.

I'm kind of sad about this, but I think that Golang will eventually replace
Python as the go-to back-end server language (maybe even data processing).

~~~
bostik
As much as a I like Go in general, there are two pythonic things that, IMO,
really should go into the next major revision.

1: sets; in this day and age, not having sets as native, stdlib-provided data
types is simply unacceptable.[ß]

2: The ease of python's "in" keyword; being able to test for a key in a map
(or set!) without any indirection is crucial

ß: granted, IIRC python moved sets into native stdlib types only somewhere in
2.x but better late than never

~~~
c-cube
Sets don't need to be native in languages that are both fast and have a proper
type system. For example, rust and OCaml have a standard set in their stdlib,
but it's not builtin. Of course, go lacking generics makes it impossible to
implement a decent set type in it.

~~~
ZenoArrow
I wouldn't hold up OCaml as an example of how to structure your standard
library, the lack of standardisation in its standard library is one of the
remaining weak points of an otherwise excellent language. For those that don't
know, there are multiple standard libraries for OCaml, each with different
trade-offs, leading to unnecessary fragmentation.

~~~
c-cube
Agreed, some things are still missing (in particular my pet peeve, iterators;
also unicode strings). But for what it provides, OCaml's stdlib is reasonably
well designed and performs well.

------
frou_dh
I have extreme Python 2-vs-3 fatigue and that's only from seeing the topic on
news aggregators for years on end. I can't fathom how tedious the topic must
be for those actually in the Python community for the whole time.

~~~
jnbiche
The migration is done. Anyone who's not starting projects in Python 3 now will
soon be obsolete, because the community has definitely moved on.

~~~
adeelk93
Community might have, but industry hasn't. You're right, the dust has settled.
If you haven't migrated to Python 3 yet, you likely never will. All the
reasons to use 2 or 3 have already been established. I doubt there will be any
more new information that will sway people from the stance they've already
taken.

------
collinmanderson
Libraries are mostly ported at this point.

It's the applications and plugins that still need work. Here's the status in
Fedora: [http://fedora.portingdb.xyz](http://fedora.portingdb.xyz)

And history:
[http://fedora.portingdb.xyz/history/?expand=1](http://fedora.portingdb.xyz/history/?expand=1)

~~~
greyman
Yes. My friend is employed at Redhat and he told me that he also works on
porting 2 to 3 (although not fulltime), and it is a huge amount of work. They
work on it several years already, and it is still far from finished.

~~~
u801e
It's that why the default version of Python on RHEL 7.x is 2.7 instead of 3.x?

~~~
yjftsjthsd-h
Also, rhel 7 is years old now and they almost certainly won't change something
that big until rhel 8.

------
devit
Python 3 is a case study on how you should never create a new version of a
language implementation that can't load and interface with code written for
the old version.

After almost 10 years, the old version is still in use, and the new version
isn't even that much better.

~~~
y7
I don't know. The introduction of Python 3 caused massive headaches and
fractured communities, but the alternative of dealing with unattractive warts
in a language until eternity is also not very attractive.

I quite like Python 3, and most of the backward-incompatible changes it
introduced.

~~~
orangecat
_but the alternative of dealing with unattractive warts in a language until
eternity is also not very attractive._

The problem is that the only significant wart that got fixed was Unicode. We
still have the GIL, a very slow runtime, convoluted packaging, barely-usable
lambdas, and limited typing. That's a pretty lousy payoff for 10 years and
probably millions of engineer-hours.

~~~
aeturnum
The people who work on CPython were not trying to "fix" any of the things you
listed in Python 3. They seem happy with the GIL and the tradeoffs they've
made in the runtime. Guido has never liked lambdas and their poor state in
Python is not an accident.

Python might be making bad calls, but it's hard to criticized a process for
failing to accomplish things it wasn't trying to accomplish.

------
simonw
This site has been around for a very long time, but I checked it the other day
and was delighted to see that it's almost entirely green now.

~~~
philipov
I wonder if it's possible to get a time series of the history of that ratio.
Would love to plot it to see the adoption curve.

~~~
stevekemp
Sadly not, as graphite-web doesn't yet support python 3.x!

(Which is a shame, graphite is something that always feels older than it
should be.)

~~~
collinmanderson
Actually, graphite-web has made good progress in the last _day_.
[https://github.com/graphite-project/graphite-
web/pull/2139](https://github.com/graphite-project/graphite-web/pull/2139)

Carbon has Python 3 support in Github, it just hasn't been released to pypi
yet. [https://github.com/graphite-
project/carbon/blob/master/setup...](https://github.com/graphite-
project/carbon/blob/master/setup.py#L96-L99)

------
happy-go-lucky
I would like to know if fellow HNers who regularly code in Python are using
f-strings and type hints in your production code or otherwise. I often find
myself inclined to use type hinting.

~~~
ambivalence
New code at Facebook does use both. Instagram uses both extensively.

~~~
frik
Does Facebook use Python 3 for Facebook frontend website? Or in PHP/Hack?
(Facebook website frontend is well known to be in PHP/Hack)

~~~
ambivalence
Facebook's WWW is Hack. Instagram's WWW is Django on Python 3.6.

~~~
happy-go-lucky
[https://en.wikipedia.org/wiki/Hack_(programming_language)](https://en.wikipedia.org/wiki/Hack_\(programming_language\))

> Hack allows programmers to use both dynamic typing and static typing. This
> kind of a type system is called gradual typing...

I wasn't aware of such a type system, and there're many languages which use
both:

[https://en.wikipedia.org/wiki/Gradual_typing](https://en.wikipedia.org/wiki/Gradual_typing)

------
brianwawok
I notice boto as one of the top items on the list as compatible.

It has many many python3 crash bugs, especially on the MWS side. I have had an
open PR for like a year to fix one of them, and it has been ignored.

This makes me not very hopeful that being on the list means anything.

(I am exclusively python3, but I have to wrestle with this a fair bit still)

~~~
mathnode
This was quite poorly communicated for pypi consumers of python libraries, you
should switch to boto3 as stated in their readme for boto[1].

Be wary adventurer, while boto3 is super neat and a python3 treat, there
unsteady footings beneath your feet (api differences).

1\.
[https://github.com/boto/boto/blob/develop/README.rst](https://github.com/boto/boto/blob/develop/README.rst)

~~~
brianwawok
Boto3 does not support MWS. Pointing to a readme is totally not useful.

Until it does, either boto should be "fixed", or perhaps the MWS piece spun
off.

------
mraison
Nice work everyone! I’d be curious to see what a “Python 2 deprecation” page
would look like (although deprecating Python 2 support shouldn’t be the goal
of course)

~~~
gogoengie
For many of the major scientific libraries, the goal is to deprecate Python
2.7 no later than 2020:

[http://www.python3statement.org/](http://www.python3statement.org/)

~~~
dbcurtis
Considering 2.7 is EOL in 2020, I'm thinking the default policy position of
any serious library should be to deprecate 2.7 by 2020.

------
japaget
See also [https://python3wos.appspot.com/](https://python3wos.appspot.com/)
for another website that also tracks Python 3 readiness.

------
Asdfbla
Was it just the time that the ecosystem needed to adapt to the Python 3
changes or were there essential changes in the 3.x versions up to 3.6 that
made it easier to switch from Python 2?

~~~
mjw1007
Some of both (for example, % formatting got added back to bytes objects in
3.5).

Also, supporting 2.5 (or even 2.4) together with Python 3 was particularly
inconvenient, so things sped up after people stopped caring about those (which
took a long time because some people were running extended-support enterprise
distributions).

------
kompiuter
I'm planning to spend my free time in the next couple of months learning
Python, should I only learn Python 3?

~~~
washappy
As someone who asked the same question a few years back (and gladly received
the answer: Python 2), I'd suggest you learn both.

Does not matter which language you start in, as long as you can write Python
2/3 compatible code. Perhaps starting with Python 2 (and the fantastic
"LearnPythonTheHardWay") helps with this. You'll just have to unlearn a few
Py2 warts like xrange and using print statements with ellipses.

You are not being progressive, nor doing your users a favor, if you go
exclusively Python 3. Even if the language owners decided not to be backwards
compatible, your code still can be (and, IMO, proudly should).

As you arrive to a point where you want to use Python 3 exclusive language
features, you'll be at least advanced in Python enough, to form your own well-
informed opinion on the matter. I myself don't feel like library support for
Python 3 should be the deciding factor for a switch. That's like switching to
exclusively designing for a certain browser version, because most websites
render just fine, leaving users stuck on IE6 without accessible content.

~~~
Zopieux
> I'd suggest you learn both.

I'd suggest OP learns Python 3 and try really hard not to look at Python 2
ever, which hopefully shouldn't be too hard in 2017.

> as long as you can write Python 2/3 compatible code

Maintaining a Python 2 and 3 compatible codebase in a PITA. OP wants to learn
a new language, presumably to build things with it. But your advice is that
they acquire insight of all the mistakes of a language that was released 7
years ago (that's for 2.7, 2.0 was release in 2000) and will reach end-of-life
in 2 years. I'd really like to understand why in the world you would want to
learn Python 2 and its “warts“, to then discover that all this stuff are just
unnecessary pain points that were removed/refactored/cleaned up in Python 3.
In my opinion, Python 2 and 3 are two different languages and should be
treated like so.

> [not] doing your users a favor, if you go exclusively Python 3

Actually you are. If you start a project _today_ and make it Python 2 + 3, you
are forcing your users (most of whom in 2017 would be proud Python 3 users
anyway) to cope with a. all the bugs introduced by the compat code you have to
write and b. the delayed releases/bugfixes caused by the subtle Python 2/3
discrepancies you'll face one day or the other.

I will make no comment on the IE6 comparison: this isn't about corporate
employees or banking apps from the 90's.

~~~
washappy
> Maintaining a Python 2 and 3 compatible codebase in a PITA.

I maintain multiple Py 2-3 compatible codebases, both academically and
commercially. It's not hard, because I develop in Python 2, while writing
Python 3 compatible code.

Python 2 is a beautiful language as powerful as:

    
    
       import antigravity
       print "Hello, world!"
    

There is nothing a beginner can't do in Python 2 that he/she can do in Python
3.

If Python is a different language and should be treated like so, then I don't
want to switch to this other language, or have a project support two different
languages (I'd switch to Go if having to switch languages). For all intents
and purposes: Python 2 works just fine. Google did not need Python 3 when they
first released TensorFlow a year back.

> If you start a project today and make it Python 2 + 3

Then you are compatible will the largest amount of users. That's what matters
to me: Somebody on a fresh install being able to pip install my library, no
matter if it is Python 2.7+ or 3.4+. All other reasons are politics.

> this isn't about corporate employees or banking apps from the 90's.

No, it's about banking apps from the 00's and 10's.

------
Polyisoprene
Python 3 killed Python? Feels like the Perl story again, lack of backwards
compatibility or "next version will be perfect" killed the language. And
people still complain about Java, C# and others being too slow to deprecate
old apis.

~~~
minitech
Python is very much alive. Not sure where you’re getting that. Perl 6 and
Python 3 aren’t really remotely comparable, either.

------
zmmmmm
It's great that finally the popular packages are pretty much all supported.

But the question is, is that really the problem? It's a bit like Microsoft
Word: so many alternative word processors implement all the popular features.
So what's the problem? The problem is, nearly everybody has some obscure
feature they depend on. So even if an alternative has all the popular
features, still almost nobody can use it. I think the constant referral to how
many "popular" packages support python3 leads to a bit of false sense of
optimism in the python world: it's perfectly possible to support all the
popular packages with Python 3 and yet have it be unusable for a large
percentage of users.

~~~
zzleeper
I was burned by that problem two years ago, but I tried again recently and
absolutely everything was supported. Heck, it's starting to be the case that
py2 is not supported anymore..

