
Python 3 in 2016 - jaxondu
https://hynek.me/articles/python3-2016/
======
retrogradeorbit
I've done a lot of Python for many years and its all been Python 2. Python 3
seems to be a decent improvement, and if I was working on a Python 3 project,
that would be fine. But when it comes to _new_ projects, I struggle to find a
compelling reason to use Python at all, when there are so many amazing
languages now to choose from. With a new project you could choose Scala,
Haskell, Clojure, Erlang (or Elixir) or Go. And there's also the less popular
ones like Haxe and Dart. I've even been playing around with Elm. And I'm sure
I've missed a bunch of others too.

So the question for me, for _new_ projects is: why choose Python 3 (over all
the other non python options) at all? Not what's better about Python 3 than
Python 2, but what's better about Python 3 than those other choices. These
other choices all have certain areas where they have great strengths. What is
Python 3's strength when compared to these other languages? It's a mutable,
imperative, single CPU bound language that can't target the browser and is
extremely difficult to distribute and deploy. Or have these issues been fixed?

I don't mean to troll any Python fanboys. I use Python 2 every single day at
work and I'm very happy with it. But what does Python 3 offer that other new
languages don't? Because when you are starting a new project you can choose
_anything_. Why should I choose Python 3 for my new projects?

~~~
andrewstuart
I never thought I'd say it, but I'm loving programming the new ES2105 version
of JavaScript. It really has a great deal in common with Python now. Clearly
many programming languages are converging as they implement common good ideas
from other programming languages. That's going to mean that whilst Python
might have distinguished itself in the past for being streets ahead, in the
future it's likely that many languages will also have many of those same good
ideas incorporated.

I posted about it:

What language has decorators, generators, comprehensions, modules, but isn't
Python?

[http://fourlightyears.blogspot.com.au/2015/08/what-
language-...](http://fourlightyears.blogspot.com.au/2015/08/what-language-has-
decorators-generators.html)

~~~
coldtea
The "all async" model of Node kills it for practical programming compared to
Python...

And the worst thing is, Node/v8's JIT would kill Python in performance for a;;
the kind of things people write Python scripts for, even if it run all
synchronous.

It would be nice if callbacks/promises/async-await were only optional and for
network/web things, not for everything.

~~~
goldbrick
You can still use the "-Sync" versions of functions in the standard lib.

~~~
coldtea
Yes, but not hundreds of thousands of npm libs.

------
wiz21c
Since everyone gives anecdotal proofs that Python 3 is just fine, I'll give
mine as well. I've migrated to Python3 a rather big project (for the unicode
handling) and although it was not quite easy, it'just fine now. I'm active in
Qt, web, json, sql domains and I've never needed a library that is Python 2
only. Thus from my own point of view, the Python 3 ecosystem is just complete
now. Super.

~~~
EvanPlaice
I think the biggest barrier to adoption right now is OS support. OSX still
comes bundled with python2. There's no indication that Apple is working on a
transition to 3.

Ubuntu is actively working on the transition but the current LTS release (ie
the one companies/enterprise will use) is still locked onto python2.

The same can likely be said for other flavors of *nix.

From a user's perspective, python3 has been ready for 'prime time' for a
while. From an OS, systems, enterprise perspective python3 still is still a
ways out.

~~~
emmelaich
I suspect that many Pythoners will install Python3 (with homebrew) or other on
OSX (and whatever other platforms still come with just Python2)

~~~
hynek
I would recommend to even use pyenv
([https://github.com/yyuu/pyenv](https://github.com/yyuu/pyenv)) that will
allow you to install _any_ Python version in your home directory (i.e. not
fucking up your system installation).

If you maintain many FOSS libs like I do, together with tox it's priceless.

~~~
obelisk_
Homebrew installs software into /usr/local last time I checked so unless you
are doing something _really_ strange like manually overwriting system files,
you'll be hard pressed to fuck up the whole system. Personally I'd install
homebrew into /opt/homebrew.

~~~
DasIch
The real advantage of pyenv is being able to install all interpreters in all
versions. If you're developing libraries, you're going to need that.

------
zzleeper
I tried switching to 3 a few years ago and was burned by some libraries that
didn't work or worked with bugs.

Last year though I tried again and there were absolutely no problems. It's
more natural, all non-dead libraries seem to support it, and in any case I was
already using "from future import" for a while.

That said, I don't really intend to port old stuff from 2.7 if I can avoid it,
so I expect that 2 and 3 will coexist for a while even within the same firm

~~~
hynek
That’s _exactly_ the place I found myself in and that made me sum it up.

------
andrewstuart
The PyPi download statistics are constantly being quoted as though the are
some exact representation of the state of Python 3 takeup.

I'm calling this as bullshit.

How much of these downloads are computers auto updating their configurations?

How, exactly, do these stats reflect the number of people developing current
projects with Python 3?

The number of legacy projects written in Python 2 will be vastly higher than
the number of Python3 projects currently in development. Maybe that's what is
being updated.

When a statistician does an analysis of what these numbers really mean I will
believe them but until then the numbers mean precisely nothing. Or more
accurately, they seem to mean exactly what the Python 2 diehards want them to
believe.

My assertion is that Python 3 is very actively and healthy and the PyPi stats
are just lies, damn lies and statistics.

~~~
hynek
Hmm I’m not sure how to take this comment. The main point of the article is
basically that those numbers don’t tell the whole story (even explicitly in
footnote 1).

~~~
andrewstuart
Your post gives the stats some level of credit when really they tell
absolutely nothing, or more precisely they tell a tale that is so open to
interpretation as to mean nothing at all.

There's no gloom around Python 3. Lots of people support it. The highest ever
upvoted post on Reddit/r/Python was a post asking to remove training material
that asserts that Python 3 is irrelevant.
[https://www.reddit.com/r/Python/top/](https://www.reddit.com/r/Python/top/)
There must be alot of people who feel positively about Python 3 to vote it up
that high, presumably at the same time that the Python 2 diehards are voting
the post down.

The appropriate message regarding the PyPi stats is not to give gentle
credence to them but to condemn them as a completely irrelevant measure of the
success or otherwise of Python 3.

~~~
hynek
Hm that’s unfortunate that it comes out that way. I thought I’m just
acknowledging that people are agonizing over them and then explain why’s not a
good metric.

~~~
mkesper
Footnotes are not very explicit, nobody reads the small print.

------
baq
Python 3 is worth it not for asyncio and unicode (though these are very good
reasons if you care about them). It's worth it due to 21st century exception
handling, which breaks down in Python 2 in a spectacular fashion the moment
you raise in your except: clauses.

~~~
hynek
Ah yeah the small nice things. `raise from`, `__traceback__` on all raised
exceptions (instead of dicking with `sys.exc_info`), `nonlocal`, `super` …

------
agentgt
I used to write a lot of personal Python scripts (ie ~/bin). I mainly did this
because I seem to always screw up bash scripts and just can't remember all the
conditional flags ie ([[-z ]] and error handling with bash for me has always
been tricky.

However in the last couple of years I have dropped Python in favor of Groovy
in part because I know the JVM and its plethora of libraries so well. Groovy
is a highly underrated language. Really my only complaint is the startup time
is not nearly as fast as Python but it does seem faster than say Clojure
scripts. Also one of the things that I have to say I sort of think Java got
right is that it has always been backward compatible (I know this was sort of
impossible with Python given its not really a byte code language). That is I
really don't have to worry if I write Groovy in a pre Java 5 (ie without
generics) where as with Python I wasn't sure if I should write new scripts in
3 or 2.

The other annoying thing albeit far less than Ruby is dependencies with
Python. Groovy has a complete bad ass way of just declaring dependencies in a
script (@Grab) and they will automatically be downloaded. I have yet to see a
scripting language that does this (ie dependency install on demand).

BTW since apparently any time I mention Java-like-tech on any HN post I seem
to get downvoted... I really really love Python. This was not to denigrate
Python or that Groovy is better than Python.

~~~
vorg
> I really don't have to worry if I write Groovy in a pre Java 5 (ie without
> generics)

Groovy has many incompatible changes between versions, esp from 1.8 to 2.0 but
also 1.7 to 1.8, 1.6 to 1.7, etc. Many sites provide Groovy 1.8 as the default
because no-one there wants to bother with upgrading.

~~~
agentgt
Oh I guess its cause I only use it for personal scripts and only really
started using it after Groovy 2 (although I used the language before I didn't
switch from Python to Groovy till after Groovy 2).

I am also not as Groovy as I could be (ie write like its Java at times) so
maybe thats why I haven't ran into issues.

------
fideloper
Python3 is still broken in some important ways (virtual environments) on
Debian/Ubuntu, which make it a but of a pain to use both in development and
production.

Example: Ubuntu 14.04 (and later versions) come with Python 3.4, but pyvenv is
unavailable (just try searching ubuntu 14.04 pyvenv to get an idea).

This bug from 2014 is still relevant, although at least the "python3.4-venv"
package is available to patch it enough to get going.
[https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/129...](https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/1290847?comments=all)

------
jorge-fundido
I don't understand the python2 vs python3 fuss. Maybe I'm not doing anything
interesting enough, but I find it fairly easy to write code that runs in
python >= 2.7 and python >= 3.3. If I was working in a python2-only code base,
I would just baby-step it towards python3 compatibility. It doesn't have to be
a complicated, disruptive task.

~~~
nas
Things are a lot easier with recent versions of Python 3. Not spending more
time on supporting 2/3 compatible codebases was a big mistake in my opinion. I
think Guido had the idea that everyone was eventually going to run 2to3 and
then be done with the conversion. There is too much Python 2 code out there
for that to work. Python 2 was too successful and businesses have no inventive
to convert working apps.

The %-formatting (printf style) for bytes is a big deal (introduced in 3.5).
Putting a 'u' prefix in front of text strings and 'b' in front of byte strings
will not go a long way in making things work.

~~~
ant6n
Next step: bring back print.

For my code base, I'm mostly worried about division being different, which
will introduce silent errors when integer types break down (or up?) into
floats.

------
dethos
Unless it is explicitly necessary to use python 2 (like legacy stuff, that
hasn't been upgraded yet), I've been using python 3 solely for almost 2 years,
and there is no turning back. I have no reason to stick with the old version.

The last piece that needs to change, to complete the transition, is the
majority of OS makers to bundle python3 by default.

~~~
collyw
I would be as well, but many jobs out there involve existing code on python 2.

------
srathi
We are using Python LDAP library[1] at work, but it is not available for
Python 3 yet. Is there an alternative?

1 [https://pypi.python.org/pypi/python-
ldap/](https://pypi.python.org/pypi/python-ldap/)

~~~
hynek
Yes!

RedHat needed it too and forked the project:
[https://pypi.python.org/pypi/pyldap](https://pypi.python.org/pypi/pyldap)

------
paulhallett
We've been using Python 3 since we implemented a new service architecture and
it's been an easy transition for our 50+ engineers.

------
czep
I, for one, must admit to having almost completely ignored Python 3 until very
recently. One thing I discovered that is way awesomer than you can imagine is
Unicode handling: it just works! I'd say Unicode was a tricky issue in 50% of
Python projects I've worked on in the past, but with Python 3, none of that
matters anymore.

------
gloves
Been thinking about learning to code, and a lot of people have recommended
Python as a good language to begin with. Taking a look at this, should I be
looking elsewhere?

~~~
hodwik
If you decide to learn Python, I'd suggest going through the Learn Python the
Hard Way book. It's excellent.

~~~
hodwik
Weirdest downvotes I've ever gotten.

------
Walkman
In practice: inheriting from "object" every time is not a big deal, but losing
the possibility to use Pypy or Kivy is huge.

~~~
MollyR
This is my problem as well. I love using Kivy instead of tkinter, and Pypy.

------
draw_down
The problem is not Python 3, the problem is keeping both languages in my head
at the same time. I'm tired of caring whether "print" is supposed to be a
function or not, I just want to print something.

~~~
orpheansodality
Why not just always use print() as a function? That's only a single mental
change, and works in both 2 and 3.

~~~
witty_username
print isn't a function (even though print("hello") works) in Python 2. But you
can use __future__ to make it a function.

------
vegabook
Three is (finally) likely to win, if only because of the constant nagging of
the project leaders, and the fact that some distros will now move to it by
default. But it will be a pyrrhic victory because it will have been a force-
feed, not an enthusiastic, willing, adoption by the community. As a result of
this mess, while Python's inertia is huge, its momentum is slowing. Its
leadership, having lost credibility, cannot really lead effectively anymore.

It will continue to be a massive, unavoidable language, but something of the
magic of when I first learned it, has been snuffed out.

~~~
hynek
That’s only true for people who are part of the community for a long time.
Newcomers don’t understand what the fuss is about and why anyone would want to
use Python 2.

My own Python bubble is more like what you described (although the mood is
improving IMHO) but talking to newcomers is eye opening.

------
osullivj
I code in both 2 & 3, and had been nervous about that. New stuff with low
dependencies in 3, and older stuff with Python C API dependencies in 2 (eg
spreadserve.com). I was worried that the move to 3 would force migration of my
2 based code, so I'm reassured rather than alarmed by this article. The
cognitive load switching between two Python dialects isn't as bad as, for
instance, switching between C++ with and without STL & Boost.

------
cdnsteve
On the web framework side of things, who is using aiohttp (web) and something
like API-Hour? Seems like the performance is really great. Python 3 asyncio.

It's hard to find people blogging about it, not sure why? It seems like a
great combination.

[http://blog.gmludo.eu/2015/02/macro-benchmark-with-django-
fl...](http://blog.gmludo.eu/2015/02/macro-benchmark-with-django-flask-and-
asyncio.html)

------
esaym
I've debated jumping from perl only dev into the python world for a couple of
years now.

I've got a list of Django youtube vids queued up on my plex server right now.
But I was thinking yesterday (while in the shower of course), perl has perl6
(which may or may not take off). But what does the future of python have?

Python 4,5,6? Any real innovative changes or just more of kicking the can down
the road (such as perl5)?

~~~
ch4s3
I think the best case for moving to Python is for the tooling around math and
data science. If you're build other types of web apps in Perl and looking to
switch to something else. I'm not sure Django is going to offer you a ton of
benefit for the switching cost, IMHO.

~~~
esaym
Well the benefit I initially see is more jobs and with a side note of
hopefully a cleaner code base.

There are not too many perl companies that have been founded in the last 10
years. And I am finding more and more that companies that are older than 10
years old and are using perl, that this usually means they haven't changed a
dang thing in their architecture or web dev process since 1998.

Which means I get to deal with CGI spaghetti, 6+ second page load times (so
count ajax anything out), and the world's worse use of javascript. I've had
good experiences with newer perl companies with short contract work, but these
older ones are killing me and I'm pretty bummed about it as you can tell. I've
worked hard to learn best practices and modern web dev styles, none of which I
can use at the older places.

------
libeclipse
I started off python learning python 3, but a few months into it, I was forced
do a project in python 2. It was a turning point, I immediately ported over
all my python projects to python 2. To me, it just seemed more simple,
elegant, and cleaner. It was the more pythonic version of python. And if I'm
still working with python after 2020, I'll be using python 2.

~~~
hepta
I don't understand this, what is more "pythonic" about 2?

~~~
hueving
Not typing 'encode' or 'decode' when dealing with strings. I know it sounds
stupid, but it's really distracting compared to everything else in python that
just flows easily.

~~~
mkesper
Then you're doing it wrong. Sorry but that's definitely better solved in
Python3 than in 2. Always decode/encode when opening a file/stream/whatever
and only use unicode internally.

------
emmelaich
It's quite possible that someone will come up with a good enough automatic
2->3 converter which alleviate the situation.

~~~
icebraining
python-modernize[1] tries to automatically make your codebase compatible with
both Python 2 and 3, using 2to3 and six[2] underneath. I haven't tried it yet,
though.

[1] [https://github.com/mitsuhiko/python-
modernize](https://github.com/mitsuhiko/python-modernize)

[2] [https://pypi.python.org/pypi/six](https://pypi.python.org/pypi/six)

~~~
brettcannon
Armin handed over development and now Modernize is actively developed at
[https://github.com/python-modernize/python-
modernize](https://github.com/python-modernize/python-modernize)

~~~
icebraining
Oh, thanks!

------
mangeletti
For anyone hesitant because they're worried they will need to support 2.x
installations at some point, there is 3to2[1]. You can write for 3.5 only, and
then back port only if you need to.

1\.
[https://pypi.python.org/pypi/3to2/1.1.1](https://pypi.python.org/pypi/3to2/1.1.1)

------
jdlyga
My main gripe about Python 3 and Python in general is that it really needs a
good method of distribution. Sure there's PyInstaller, but it's not
straightforward enough and there's a lot of mystery problems that take a lot
of time to figure out.

------
amstocker
I think this is a nice healthy view to have about Python 2 to 3. Can't wait
until python 4!

~~~
EvanPlaice
I seriously doubt 4 will include breaking changes, at least not to the
semantics/syntax of the language itself.

What python _really_ needs in 4 is better unified package management and
distribution support. They have a lot to learn from the Javascript and Ruby
evosystems.

~~~
crdoconnor
>They have a lot to learn from the Javascript and Ruby evosystems.

Such as?

I really hope I'm not going to start needing 1,200 dependencies to build a
simple app like I would in node.

~~~
EvanPlaice
Support for local, per-project installs without hacks like virtualenv.

Per-project configurations to map things like external dependencies and
project info. Setup.py + MANIFEST is not the answer.

Better suport of versioned deps so multiple versions of the same dep 'just
works' when its neessary.

Better package publishing for library maintainers. Have you ever published a
pckage to PYPI? It's a huge pain.

Support for Markdown-based documentation on PYPI. ReStructuredText is cool and
all but MD os the defacto standard

Standard support for direct install from GitHub without weird hacks.

Pick one unified standard and deprecate the rest. The current 3, distutils,
distutils2 and setup.py all suck.

Write some halfway decent docs on how to publish packages. I spend more time
on Stack Overflow that the python docs every time I publish a package.

Dependencies are used so heavily in the JS/Ruby ecosystem because it's
extremely easy to publish a package and the package manager 'just works'.

~~~
crdoconnor
* Virtualenv isn't a hack.

* Setup.py/MANIFEST.in seems like a pretty clear answer to me.

* I've worked with python for about 10 years and only once have I come across two packages that required conflicting versions that I wanted to deploy in the same environment.

* Yes, I do it pretty frequently.

* "MD os the defacto standard" Huh? According to whom? ReST is fine.

* "Standard support for direct install from GitHub without weird hacks." \- stick "git+[https://github.com/yourname/yourpackage"](https://github.com/yourname/yourpackage") in your requirements.txt and off you go.

* Yeah, they should really standardize on pip, but this is relatively minor.

* Use one of the templates.

* Yes, I hear somebody even published a package that checked if a number was negative. And it had a bug.

------
hathym
can we please stop writing articles in twitter?

[https://twitter.com/hynek/status/699928792752594944](https://twitter.com/hynek/status/699928792752594944)

------
angvp
Not going to happen IMO, yet no advantages to do the transition.

~~~
mrweasel
The Unicode support alone justify transitioning for us.

------
moistgorilla
This is the ultimate HN circlejerk comment

>Scala, Haskell, Clojure, Erlang (or Elixir) or Go. And there's also the less
popular ones like Haxe and Dart

Are you kidding me? Did you just list the languages you see threads on HN
about? Scala and Go I could maybe understand if you needed the performance but
the rest of the choices are just bad. Especially if you are trying to start a
business instead of a functional programming bootcamp.

Also there is nothing inherently more difficult about deploying and
distributing python compared to any of the languages you chose.

~~~
dang
Please don't be rude in HN comments.

We detached this subthread from
[https://news.ycombinator.com/item?id=11124822](https://news.ycombinator.com/item?id=11124822)
and marked it off-topic.

------
ivoras
Since it's basically all anecdotal, I'll say my gazing-into-the-crystal-ball
educated-guess feeling that Python 4 will make the entirety of Python about as
popular as Perl is today if: it doesn't get rid of GIL _and_ at the same time
implement a JIT compiler, _and_ at the same time remain 100% .py source-code
compatible with Python 3.

The developers have dug themselves into this mess with frivolous differences
("print" a function, wanting to remove the "%" string operator, etc.), instead
of spending the years on more productive features, now is the chance to dig
themselves out again.

It's a beautiful language, too bad the development choices were a bit sketchy.

~~~
orf
Comments like this are so misguided and yet so common on HN. Adding a freaking
JIT to CPython is a ridiculous suggestion that will never happen for a whole
load of reasons. Getting rid of the GIL is more noble, but seems impossible to
do without breaking compatibility.

Python 4 will just be the next release after Python 3.9.

~~~
plesner
> Adding a freaking JIT to CPython is a ridiculous suggestion that will never
> happen for a whole load of reasons.

That's a bold statement. Can you elaborate on what those reasons are?

~~~
orf
It's not a bold statement, it's one made time and time again by the cPython
developers. In short:

1\. The Python language itself doesn't lend itself to being JIT compiled -
it's too dynamic.

2\. cPython is the reference implementation. It's source should be as simple
as possible.

3\. Only a subset of Python programs would benefit, and the rest would be
slower/more memory hungry

and finally,

4\. If you want/need a JIT then use PyPy, in all it's glory with all its
upsides and downsides.

PyPy is a big project with a lot of very very very smart people working on it.
They've done an excellent job at JITting Python (and creating an impressive
interpreter framework) but even they couldn't make a JIT that is anywhere near
suitable for inclusion in cPython. A bunch of cPython hackers on python-dev
have no chance.

tldr: Want a JIT? Use PyPy.

~~~
plesner
By "bold" I'm also referring to your use of the words "freaking" and
"ridiculous".

1\. This was also said about JS before people just went ahead and wrote JITs
for it. Are you sure what they're saying isn't " _we_ can't make a JIT for
python" rather than " _nobody_ can make one"? Because that's how it turned out
with JS.

2\. If given the choice, do you think the community would turn down a JIT to
avoid making the reference implementation more complex? To whose benefit is
that requirement? I've never heard people complain about other languages that
they didn't have an easy-to-read reference implementation.

3\. I've not heard this reported as a problem in practice for languages that
have a JIT. It's usually toy programs where the JIT overhead is significant
and they're so small and short-running that neither slowdown or extra memory
is usually an issue.

4\. Not everything that runs on cPython runs on PyPy so that's not a choice
I'm necessarily able to make.

I'm not saying there aren't reasons to not have a JIT in cPython. But it's a
choice not a natural law. And it's not ridiculous to suggest that they could
make a different choice if they wanted, as JS eventually did.

~~~
jerf
JITs for Javascript aren't comparable; at the time, nobody had C-based
extensions for Javascript. It makes it a radically simpler problem.

Remove the "maintaining compatibility for C-based extensions" requirement, and
you get, well, PyPy. And you also get a community split that makes 2/3 look
trivial. Vast swathes of core Python code and libraries are really not
"Python", but Python C-based bindings to custom code or C libraries.

~~~
plesner
Sure there were C-based extensions for JavaScript, that's how it integrates
with the DOM. It makes it a little trickier but not a whole lot.

~~~
jerf
Sorry, perhaps I was unclear. I mean, there were no C-based extensions not
under the control of the same project as controlled the JS engine, so one
entity can both JIT a JS engine and simultaneously make whatever modifications
it took to make them work under the new engine. Python has an enormous amount
of _external_ C-based extensions not controlled by any one entity, which
constitute huge swathes of core (in importance, not in "under control of the
core team") Python libraries. It's difficult to imagine what a JIT looks like
that still works with those. You don't have one entity doing both the JIT and
all the C extensions.

