top | item 6990481

Python 2.x vs 3.x use survey

104 points| janzer | 12 years ago |surveymonkey.com | reply

114 comments

order
[+] jordigh|12 years ago|reply
For Mercurial, this is the biggest problem with Python 3:

http://bugs.python.org/issue3982

They got rid of format for ordinary strings, and since we have to use bytestrings for handling hg's binary format, converting back and forth with .decode and .encode just to get the formatting is a lot of work.

The Python devs have actually acknowledged this use case and apologised to hg. Kinda weird, considering how Python itself is hosted with hg. :-/

[+] gejjaxxita|12 years ago|reply
That was opened five years ago, bizarre.
[+] Groxx|12 years ago|reply
Why not write it yourself, as a utility method rather than something built-in? Granted it would be nice to be built in, but that shouldn't stop anyone. Or is there some other reason?
[+] crag|12 years ago|reply
"Do you think Python 3.x was a mistake?"

That's where I stop filling out the survey.

And that's the python community biggest problem. Moving forward, everyone needs to pick a version (and I'd pick 3). A new user just sits and spins his head. Even the training materials are all over the place.

[+] zephjc|12 years ago|reply
I don't think it's a leading question - I think if they get a large enough sample size, it will be a worthwhile survey of the Python community's 2/3 behavior.

Ultimately, you did pro-Python 3 supporters a disservice by not speaking up.

[+] comicjk|12 years ago|reply
I think that's a very significant question. I would guess that 50%+ of Python users don't use Python 3, and thus would be counted as anti-Python-3, if not for that question which allows them to say "I don't think Python 3 is inherently a bad idea."

It would be nice if the question were more specific and more positive, but the survey would be worse if it were simply taken out.

[+] DonGateley|12 years ago|reply
Depends on how you interpret "mistake." I don't think that improving the language is necessarily a mistake, but the way they did it is a mistake. It should have been an absolute requirement that, one way or t'other, a user could employ 2.x libraries transparently. No change should have been allowed until and unless a way was found to make it not impact backward ecosystem compatibility. This is a law of nature that was ignored and 3.x is paying the price that anyone could have predicted (and most did.)

Not ensuring library compatibility was lazy, egotistical arrogance and will ultimately relegate 3.x to being a historical footnote.

[+] Patrick_Devine|12 years ago|reply
I really wish there was an "undecided" option for that particular question. I said "yes", but only because I think having backward compatibility trumps cleaning the language up.

It's like any software project. It's always tempting to throw everything out and start fresh, but that always takes about 100x more work than what is budgeted for.

[+] falcolas|12 years ago|reply
I wouldn't, not yet. There's not enough support. Great ideas, but the support isn't there for it yet: not in libraries, not in operating systems, not in documentation.

I don't think Python3 was a mistake, but the migration is going to take time. Cutting off either group would have been a terrible decision, and I'm glad they didn't.

[+] srobertson|12 years ago|reply
I have problems with the way this is worded as well. I don't think Python 3.x was a mistake. I think the mistake is continuing to develop it in parallel with 2.x with no definitive end of life for 2.x is the mistake.
[+] deckiedan|12 years ago|reply
Dear Apple. Please include python 3 as /usr/bin/python3 in all future Releases. And Microsoft, if you're listening, it would be extremely sweet if you would install python by default as well...
[+] xradionut|12 years ago|reply
Microsoft would prefer you to use PowerShell and Visual Studio. Python wasn't invented in Redmond.
[+] _random_|12 years ago|reply
Would be cool to include latest Mono into all major *nix distributives as well.
[+] tsuraan|12 years ago|reply
The biggest thing that drives me nuts about py3 is just that its repl doesn't evaluate generators. I'm sure they had their reasons, but I use python as my go-to calculator, and when simple operations with maps/ranges give me a representation of a generator ("<map object at ...", whatever), then it's just less useful to me. I could be alone in that use case though...
[+] bluecalm|12 years ago|reply
Those things return generators now to avoid wasting memory (you don't need to create possibly humongous list and keep it in memory during the iteration). If you want a list, just do list(your expression). If you forgot about it then do: list(_) as the very next thing. Like this:

>>> map(lambda x: x*x, range(1,10))

<map object at 0x02DDDB90>

>>> list(_)

[1, 4, 9, 16, 25, 36, 49, 64, 81]

Wtp ?

[+] dragonwriter|12 years ago|reply
> The biggest thing that drives me nuts about py3 is just that its repl doesn't evaluate generators.

If by evaluate you mean "convert to a list", that's sensible, since a generator may or may not be safe to convert to a list. If you want a list, wrap the generator to a call to the list() builtin function, and, voila.

[+] falcolas|12 years ago|reply
Neither does Python2.

    $ python
    Python 2.7.5 (default, Aug 25 2013, 00:04:04)
    >>> xrange(10)
    xrange(10)
    >>> list(_)
    [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
[+] maxerickson|12 years ago|reply
It's really only a solution if the calculator usage is on a small number of computers, but you can just import * an override of the map function that behaves however you want.

The override is easy:

  pymap=map
  def map(...)...
(and maybe for calculator style usage you would name your list returning map and range m and r, which would also help with not confusing them with the usual behavior)
[+] teddyh|12 years ago|reply
Write it as a list comprehension instead; it has identical syntax except for using square brackets instead of parentheses, and returns a list.
[+] zephjc|12 years ago|reply
Consider a generator that yields results indefinitely, or even merely millions of results. Are you still sure you want those printed to the repl? :)
[+] nixarn|12 years ago|reply
Only reason I still use 2 over 3 is that 2 gets the job done, is well supported and I don't see a big enough reason to move to 3. If 3 had a big performance increase, then maybe I would switch. Anyhow, I'll probably move to 3 at some point just because at some point more people use it (more code on the Internet in 3, more StackOverflow answers in 3 etc.)
[+] ddebernardy|12 years ago|reply
The survey is missing sets of answers for users who rejected or moved away from python because they were turned off by the disconnect between core devs and the community when python 3 got released.
[+] falcolas|12 years ago|reply
I can't say I understand this attitude. It's analogous to cutting off your nose to spite your face. Both Python 2 and 3 are actively supported, and there's a clear migration path defined. The migration isn't complete yet, but it's progressing at a development friendly pace.

I say this as someone still on Python 2.6 due to environment restrictions.

[+] dec0dedab0de|12 years ago|reply
Missing a question. "Would you switch to python 3 if they brought back the print statement"

Edit: I really just like the statement for the interpreter, and IPython Notebook. To me the statement syntax feels less like programming, and more like using a computer.

[+] dded|12 years ago|reply
Personally, I prefer function. I can understand that others have a different preference; what I find surprising is the number of people who seem to care so much about this. Nevertheless, it is very evident that you are not alone.
[+] Kliment|12 years ago|reply
I don't mind the print statement/function thing but I am bothered by the pain when dealing with byte strings. I use Python to talk to hardware that doesn't speak unicode, the contortions I have to go through to get byte strings to behave correctly on py3 are frustrating. I have no problem with the default string being unicode, but why can't byte strings be implemented like the unicode strings were done on py2.x?
[+] viraptor|12 years ago|reply
Is there some story behind it? It looks like the smallest issue out of the whole migration. (especially with from __future__ import print_function)
[+] wonjohnchoi|12 years ago|reply
What is the advantage of python 2 print over python 3 print? I believe that python 3 print can do everything python 2 print can do on the same level of elegancy. Also, python 2 print has a weird trailing-comma syntax. When a trailing comma is added to a print statement, a space is printed when another print statement is used. For example,

print 'hi', # prints hi (no extra space in the end)

print 'hi',; print 'hi' # prints hi hi

I personally dislike this syntax because I don't find this natural. Wouldn't it make more sense to print an extra space after the print statement with trailing comma instead of before the next print statement?

[+] ballpark|12 years ago|reply
It would be nice if we could see the results
[+] analog31|12 years ago|reply
In my view, the importance of the 2 vs 3 issue depends on who you think the typical Python user is, and the user population may be changing rapidly.

I'm not a CSist or professional programmer. I use programming as a tool, typically to solve short term problems for myself or for a small circle of colleagues. When I started using Python, not too long ago, it seemed like I had discovered a secret productivity tool. A project manager asked me: "What's a Python?"

Today, Python seems to be everywhere. It's been taken up by curious characters such as scientists and hobbyists. It seems to be the lingua franca of the Raspberry Pi. My non-CSist colleagues are getting into it, and I don't think it's just because of my incessant evangelism. ;-) A great thing about Python is that you can use it at whatever skill level you happen to be at, by ignoring its advanced features until you need them.

I could switch from 2 to 3 today, but I'm lazy. I'd get bonked by errant print statements for a while, and probably not experience any other hurdles. I spend more time already, keeping up with the changes that I make to my own libraries.

[+] bobx11|12 years ago|reply
I may be old, but this just reminds me of Larry Wall's Perl 6 and in my opinion Python 3 should have been a hobby project / incubator for changes that could be introduced to Python 2 eventually.
[+] davvid|12 years ago|reply
I'd also like to see the results. Curious, did you create this survey to see if there would be interest in a long-running Python 2.x fork?

IIRC the Python community was already expecting a fork to happen eventually (because 2.7 is the "final" 2.x release) so getting the community involved would be a good thing.

I would imagine that the purpose of maintaining 2.x would be for fixes, security, and back-porting of features that make it easier to have 2.x and 3.x-compatible code.

[+] brownbat|12 years ago|reply
I'm curious what the Python 3 adoption status is inside of Google, which I think of as a place that's relatively pro-Python, very pro-new stuff, but also possessing a lot of institutional inertia and giant amounts of code. Have parts of Google overcome the inertia and switched to 3? Do fights break out in the halls? Is it 2 forever and always?
[+] sontek|12 years ago|reply
I don't think people realize how easy it is to run a Python2 and Python3 codebase at the same time if you have decent test coverage and run tox.

Before PyCon SurveyMonkey(my employer) will be deploying a major part of our application on Python3.

[+] kccreator|12 years ago|reply
I don't really have a strong reason to prefer 2.x, but I'm stuck on it as I mostly (exclusively) use Python on Pythonista for iOS.

But I'm fascinated by the debates over the merits of the two. Thanks for posting the survey!

[+] gejjaxxita|12 years ago|reply
There was a dynamic graph somewhere showing the number Python 3 and Python 2 packages on PyPi against time, no amount of googling can find it, does anyone know what I'm referring to? I'd love that link.
[+] wheaties|12 years ago|reply
My only question is... does Gunicorn+Gevent work on Python 3 yet? Last time I checked one worked and the other only had a branch which you could use but wasn't in master yet.