
Python 2.x vs. 3.x use survey - bru
https://docs.google.com/forms/d/1DqxkNi4GvyTCu54usSdE1DjW29zw1tc52iMeH3z4heg/viewform?c=0&w=1
======
bru
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](https://news.ycombinator.com/item?id=6990481)
"Python 2.x vs 3.x use survey"
[https://news.ycombinator.com/item?id=7005711](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.

~~~
svisser
Where will the results be published?

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

------
agentultra
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.

~~~
merlincorey
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?

~~~
maxerickson
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]
        >>>

~~~
merlincorey
Ah, I actually _like_ that!

That is indeed cleaner. Thanks for the explanation.

~~~
agentultra
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.

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

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

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).

~~~
viraptor
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.

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

~~~
viraptor
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.

------
vegabook
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".

~~~
falcor84
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...](http://ipython.org/ipython-
doc/dev/interactive/reference.html#automatic-parentheses-and-quotes)

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.

~~~
bufordsharkley
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?

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

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

~~~
Alex3917
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.

------
falcolas
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.

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

~~~
bashinator
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.

------
arenaninja
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

~~~
dschep
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.

~~~
arenaninja
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](https://twitter.com/danilobellini/status/461653494295179264))
at that time, or things might have turned out differently

------
tesq
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.

------
jlawer
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.

------
hpaavola
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](https://bitbucket.org/userzimmermann/robotframework-python3)) which I
might use next time I get to start writing RF libraries from scratch.

------
deckiedan
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.

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

~~~
ylem
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.

------
Animats
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.

~~~
pekk
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

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

~~~
JelteF
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

------
Mikhail_Edoshin
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.)

------
jpiabrantes
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.

------
Svenstaro
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.

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

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

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

~~~
bcj
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.

