Hacker News new | past | comments | ask | show | jobs | submit login
Python 2.x vs. 3.x use survey (docs.google.com)
124 points by bru on Dec 10, 2014 | hide | past | web | favorite | 70 comments

Last year a survey was conducted on python 2 and 3 usage.

It sparkled interesting discussions on HN: https://news.ycombinator.com/item?id=6990481 "Python 2.x vs 3.x use survey" https://news.ycombinator.com/item?id=7005711 " Python 2.x vs. 3.x survey results"

Here is the 2014 edition, slightly updated (from 9 to 11 questions). It should not take you more than 1 minute to fill. I would be pleased if you took that time.

The results will be published around the end of the year.

Can I sign up for something to see when the results are released?

Where will the results be published?

On python.org as well as where I published the survey: here, python-dev@python.org, comp.lang.python, /r/python and /r/programming

I suppose on the python.org frontpage as last year.

I write all of my side projects in Python 3.4. I only write 2.7 because I work on Openstack at my day job. I avoid the use of Python 2 in every situation I can.

Python 3 has better modules built-in; the existing modules have been cleaned up; a cleaned up language (no more xrange, lazy map/filter/reduce, explicit byte-stream encoding); an improved language (sub-generators); optional type annotations; configurable allocators (in Cpython).

I just prefer it to Python 2 these days.

edit: And all of the upstream effort into making the language better is going into Python 3.

As one of those crazy functional programmers who uses python, can you please explain to me what the benefit is in remove xrange, lazy map/filter/reduce, and other functional mainstays in exchange for what is essentially more syntax to do the same?

It's the other way around, they are not removed, the default implementations are now lazy. So in python 3 you get an interator:

   >>> map(lambda i:i*i, range(5))
   <map object at 0x010622F0>
and have to explicitly construct a list:

    >>> list(map(lambda i:i*i, range(5)))
    [0, 1, 4, 9, 16]

Ah, I actually like that!

That is indeed cleaner. Thanks for the explanation.

Traversing a binary tree without an explicit stack is also much cleaner thanks to sub-generators.

    if tree.left:
        yield from traverse(tree.left)
    yield tree
    if tree.right:
        yield from traverse(tree.right)
As a trivial example.

well, range in python 3 is lazy. They replaced the non lazy implementation with xranges impl.

Same applies to map, filter and I believe reduce as well.

> I write all of my side projects in Python 3.4. I only write 2.7 because I work on Openstack at my day job.

And that's the issue.You cant be a pro pythonist unless you know both,even if you prefer 3.x .Not saying 2.x is an entire different language.Still,Python devs have to know the differences between both versions.

Let's just be thankful for OpenStack dropping support of Python 2.6!

Something I can't wait for my day job to do. At least we mostly stopped using 2.3...

I was super turned off of Python 3 when it came out and I promptly tried it and ran


and was confronted with

UnicodeDecodeError: 'utf-8' codec can't decode byte 0x80 in position 2: invalid start byte

If I had realized at the time that this error would be averted with

open("/dev/urandom", "rb").read(20)

I might have felt more charitable and less shocked (although I can see in retrospect that there's quite a good reason for this error, I might have preferred for the default file type to be binary -- presumably something that was debated extensively inside the Python 3 development effort).

Your first version was already not correct/portable. When reading binary files on Windows, you have to include the binary mode. Otherwise you'll drop bytes semi-randomly.

This change only made that mistake visible on other systems.

There is no /dev/random on windows anyway. Not every piece of code has to be portable.

It doesn't have to be, but going for a more correct/portable code (than absolutely necessary minimum) helps avoid such problems. In this case binary file was opened - if the "rb" mode was added anyway, the exception mentioned above wouldn't happen.

Edit: Actually python doesn't even mention windows. It's simply "Add a 'b' to the mode for binary files." (in python 2.7 documentation) According to the docs it should be specified regardless.

Yes, I definitely wouldn't have expected or intended that code to work on Windows.

The easiest version is the most portable and easy to read in this case:


Saves you from having to manage files at all, and works cross-platform.

Huh, I never knew that was there; thanks!

In production code I would probably use Crypto.Random.get_random_bytes().

Let's be honest. The fact that surveys like this are still around 6 long years later has just become boring.

I have moved to Python 3 purely because of asyncio. There is no other reason that I have found Python 3 to be compelling for. When I write Python 3 now, I feel like my favourite language has gone all "serious" on me, like it wanted to grow up, and has lost a lot of its charisma on the way. I actually liked the print operator for example - it's probably the reason I chose python in the first place when I saw

  >>> print "hello world"
for the first time. That's it? So clear and simple!

3.0 has lost some of that. The unicode thing is also just irritating because 99% of the time ascii works very well and is less complicated, thank you very much.

Also, no matter what anybody says, you still bump into libraries that you need that are 2.x only (in my case Bloomberg). It doesn't matter if most libraries are ported if just one library that you need is not ported yet, you're back to 2.x. Imagine you're an average coder who uses say 8 libraries. By the ratio of 15% not yet moved, you're almost certain to have a problem (1 - 0.85 ^ 8 > 70% chance). Anyway I have been able to manage because I have isolated the 2.x dependencies in another system, and I have put in the effort only because I really like asyncio, and it's finally clear to me that Python 2.x has no future. That said, and taking that logic even further, the very fact that this 2v3 issue is still around is irritating, and has been irritating a lot of people for a long time. I am wondering about going the whole way and moving to another language altogether (Golang and/or functionals).

One more thing to point out. If you're beginning in Python, the vast majority of code samples on the internet are 2.x. That's fine if you have any clue about Python as the surface differences are not that large, but it is definitely a pain if you're expecting to copy and paste and have things "just work".

I really miss the ease of the print statement and therefore was very happy to discover ipython's automatic parentheses - http://ipython.org/ipython-doc/dev/interactive/reference.htm...

Activating this option allows the parser to automatically infer function parentheses, just like in ruby. Though ruby still wins by virtue of its single letter `p` function.

The new print function does some nifty stuff, but I find it such an unnecessary breaking change to rip out the good ol' print statement.

In practice, the print statement is almost always much more convenient to use, but more than that, its removal represents to me the futility of the schism-- would it have hurt to let the canonical "hello world" continue to live as is?

FYI, there will be an official 3.x library for BLPAPI at some point in the not-to-distant future.

Meanwhile, the Python 3 Wall of Superpowers is looking really good. 166/200 major watched projects are Python 3-compatible. https://python3wos.appspot.com

Funny. I wrote a really small utility program with BeautifulSoup in Python 3. Coworker wanted to host it on AppEngine, but it supported only Python 2 for some reason. So he ported it. I am not sure what they support now, but it seems that the WoS application itself has to be in Python 2. :-)

Python 2 was supposed to be dead at least 2 years ago and still 34/200 major watched projects use it.

The google-api-python-client is what bothers me the most. They work on convincing top CS departments to teach CS101 in Python, and as soon as the majority switch it feels like they've kind of abandoned the language. From what I can gather from Github, it looks like there is all of one person working on this part time.

I don't know where you got this, but it was never planned to have been dead two years ago. 2.7.0 happened in July 2010, and regular bug and security fixing would still have been happening up until around this time regardless of anything else (fwiw, 2.6 went from 2008-2013). Instead, we decided earlier this year to extend that support until 2020.

Well, dead may be a bit strong. Old projects that use 2.x have no good reason to migrate to 3.x, and 2.7 will be supported until 2020 at least.

pylibmc was ported to Python 3.x in its latest release, but the wall of superpowers hasn't updated in days!

Indeed, it is ported. You can see updated list here: Python 3 Readiness (http://py3readiness.org)

VPython is missing there

Still on 2.x, simply because it's a lot easier to use the generally available system packages than constantly rolling/building your own. 2.x is not missing anything I need, so there's simply little incentive to migrate my code to 3.x until the package support is there.

Genuinely curious - which packages are you missing in 3.x?

I think falcolas means that python3 is not available as a native package (i.e. apt-get, yum install, etc) on the systems s/he programs for.

This reminds me of a Flask mini project I did. I was doing it in Ubuntu (LTS if I'm not mistaken). I picked python3 and ran with it. As I tried to use Python's virtualenv (venv), I went down the rabbit hole of a broken mess that was left in Ubuntu. I just reinstalled Ubuntu this week so I might give it another shot, but every time I try to do something with Python I end up with a broken mess, and that's disheartening

Ubuntu, at least some versions, ship with a horribly broken Python3. Broken because pip and virtualenv is somehow screwed up.

It's an Ubuntu bug, not Python3. Install Python3 from python.org an everything is fine, except then apt-get of cause won't give you the bug fixes.

I'm not doubting your specific experiences, but I set up a Flask project with Python 3 on an Ubuntu system myself about three months ago, and - as someone with a lot of experience with Linux and Ruby (and other things) but relatively little with Python - I didn't have much trouble. It definitely could have been easier, and I think I did have to google a few incantations to make it all work, but it didn't seem terribly hacky or messy to me, and probably no worse than getting the equivalent Ruby/rvm/Sinatra project to work.

(Other comments suggest that there are fundamental problems with Python and virtualenv and Ubuntu, so either I just fortuitously missed all of that or maybe I was in such a happy delirium of tinkering that I've now forgotten all about it.)

AFAIK -mvenv is still kaput in Ubuntu. I just this instead:

    sudo apt-get install python-virtualenv python3
    virtualenv -p/usr/bin/python3 <venv>
Yes, it'd be way cooler if -mvenv wasn't crippled in Ubuntu, but this still works fine.

Yea I was doing this until I also ran into a horrible mess later on due to the underlying issue that resulted in a catch 22 (something like pip is broken because venv is broken because pip is broken...). Unfortunately I didn't see [this tweet](https://twitter.com/danilobellini/status/461653494295179264) at that time, or things might have turned out differently

I know this is a bit of a dirty trick, but so far it has worked without problems for me at least:

The issue seems to rise from a missing ensurepip module. I fixed this by just downloading the Python 3.4 sources, unpacking them and copying the unpacked lib/ensurepip/ to /usr/lib/python3.4/ after which python3 -m venv seems to work fine.

I'm also sorry that Ubuntu broke venv, but there were many (edit: at least a few that I remember) attempts to file tickets to get that fixed in Ubuntu, lots of stupid arguments against fixing it

It definitely turned me away from Python yet again for the time being. I'm now rewriting that same project in Laravel. I understand that it's not python's fault, but every time I've tried to use it some package is broken, and the alternative is going back to python2

> As I tried to use Python's virtualenv (venv), I went down the rabbit hole of a broken mess that was left in Ubuntu.

What do you mean? virtualenv exists exactly so that your libs are installed in your local directory and not globally in the system. I'm not sure how it could result in broken mess in the system that way.

This is the bug I'm talking about: https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/129.... I think the distro was Ubuntu 14.04 LTS, but I do not remember exactly

I just use Nix (see [1]), for Python stuff and everything else. I've never tried to use virtualenv and hope I never will.

[1] https://nixos.org/wiki/Python

You could use Docker, that way your host Ubuntu is kept clean.

docker pull python:2.7

docker pull python:3

For more granular tags: https://registry.hub.docker.com/_/python/

I think the problem that is being had is Ubuntu packages. Which Docker in and of itself won't solve. All it will do is isolate packages from the rest of the OS. Which python is fairly generic, and building your own python libraries, and gutting python packages from Ubuntu will have the same affect.

Either way you are hand installing a lot of packages.

This seems more of an outlet to vent and quantify the frustration of the Python 2 to 3 migration than it is a 2 vs 3 use survey.

I transitioned to 3 over a year ago and haven't looked back. I am happy with how the ecosystem has adapted and the direction Python is taking.

Type annotations, liberal use of and expansion of syntax for generators, language cleanup and additions to the standard library really make it another and better language.

Python 2 is already on all my systems (OS X, Centos 5/6/7). Python 3 needs to be deployed.

Since I write a lot of sub 1000 line scripts for system admin tasks, it tends to not be worth forcing a Python 3 dependency just to make some small task easier.

Finally there are still a few really useful libraries that are python2 only (such as pysphere for vmware vSphere) and salt (saltstack) runs under the system python instance (py 2) that most code I write is still python 2.

Most of the code I write I try and write it so it should work on both, however without being tested and due to the nature of fairly quick development and limited testing, its almost certain there will be a few issues with running on Python 3.

Once they can convince Red Hat to replace the system python with python 3 (which will require some major work since I believe yum and a lot of other python code is not compatible), I think you will see a lot faster decline.

I mainly use Python to write Robot Framework libraries. RF needs to support Jython, Jython will not support Python 3 in near future, so I'm stuck. There is a Python 3 fork of RF (https://bitbucket.org/userzimmermann/robotframework-python3) which I might use next time I get to start writing RF libraries from scratch.

We use a lot of python stuff at work for automation, moving large video projects around, etc. And since on all the OSX machines python2 comes pre-installed, but there's no py3k, it's a lot easier just to stick with that. It also means the scripts work out of the box on Ubuntu, Debian and CentOS - although for some of our older CentOS installs I have to stick w/ 2.6, which is a bit of a pain.

Stopped using python in my research. Now I stick with Matlab/Julia.

Why? I ask because I switched from using Matlab to using python. I found Matlab was great for getting things done, but it was difficult to maintain/distribute larger projects--much less deal with interfaces to the web, etc. I also found (at the time) that parallelization was easier with python. I haven't experimented with Julia.

I stopped using Python in my research, too. Now I'm using R which is so terrible as a language that for the first two years I felt insulted every time I wrote code in it. However, I stuck with it and even like it now because it has an amazing ecosystem. (I also got used to expressing things in terms of vector and matrix operations.) Julia is promising but things are still too much in flux for my taste to consider it for serious work. I have no doubts about Julia as a language but I'm not sure if they are going to able to build an ecosystem like R's. They're not always making it easy for R developers to switch. Fortunately, some R veterans like Doug Bates are heavily investing in Julia. I hope others will follow.

Why did you stop? Surely, the 2.x vs 3.x schism didn't cause this?

That's a useless survey. Answers by random people aren't particularly useful. It doesn't reflect how much of a Python code base one is responsible for. Analysis of major code bases written in Python would be more useful.

To be pedantic, answers by randomly sampled people would be more useful than this, which is so skewed it's useless.

In either case, it's irrelevant

App Engine supports Python 2.7. this was a deal breaker for python 3 usage for me.

Google is super slow in supporting Python 3 for anything, their python API client still hasn't been ported. It's the only dependency for one of my old projects that makes it unportable to Python 3

same here. And I don't think google is putting a lot of resources in appengine (python) anymore, so I don't think this is going to change soon.

The only app I wanted to use that required v3 Python was Beancount, but I couldn't get it to work, because it required v3.3, while Cygwin only has 3.2 and I myself was unable to compile Python v3.3 or later on Cygwin. (It doesn't work as it is, I tried to google and apply patches, got it to compile, but tests failed, so I gave up; no Beancount for me.)

I wish Python 3 was never born or Python 2 got murdered when 3 was born. Both of them live at the same time it's the worst thing.

We use Python 3 for our current Flask projects with lots of dependencies without much trouble. Granted, we had to fix two libs for compatibility but it wasn't a big deal. It's pretty smooth sailing for us.

2.x since it's widely available on systems. I do DevOps work.

If Twisted Matrix isn't on Python 3 then neither am I.

Is it just me, or are questions biased towards Python2?

Unfortunately, I think they are just based on the reality of the situation. According to the person who is responsible for PyPI, ~5X as many people use 2.6 than 3.X.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact