Python 2.x vs 3.x use survey

https://www.surveymonkey.com/s/N5N5PG2

by janzer • 13 years ago

104 114 13 years ago

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.

viraptor5• 13 years ago

Is there some story behind it? It looks like the smallest issue out of the whole migration. (especially with from __future__ import print_function)

sp3323• 13 years ago

I think people would prefer "from __past__ import print_statement" in 3.x.

Kliment3• 13 years ago

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?

viraptor5• 13 years ago

What's the specific issue? I find it solves loads of issues before where you could mix bytes and unicode by accident. Not only are they more explicit, I find the fact that `b'\0'[0] == 0` - way better when working with actual bytes.

dded3• 13 years ago

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.

bcj• 13 years ago

I prefer it as well. Being able to do things like throw

    print(<SOMETHING I'M TRYING TO DEBUG>) or

into a lambda has been useful on multiple occasions.

wonjohnchoi• 13 years ago

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?

zephjc3• 13 years ago

no trailing space is a convenient shorthand - print by itself prints with a newline (so it might make sense to have print() vs println()); print + comma omits the newline and waits for the next print statement, so that

    print 'hi',
    do_something()
    print 'there'

and

    print 'hi', 'there'

both yield

    hi there

(Assuming do_something() doesn't call print itself)

infocollector• 13 years ago

Where are the real-time results? :)

ddebernardy2• 13 years ago

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.

falcolas8• 13 years ago

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.

stefantalpalaru2• 13 years ago

The migration is so difficult that you might as well migrate to a different language and solve the speed and memory usage issues while you're at it.

ddebernardy2• 13 years ago

Well, get over it and understand it...

Speaking personally, I sought to move away to a utf8-friendly language from php a few years back, and seriously considered Python back then. It came highly recommended on Stack Overflow.

Upon investigating the matter further, however, it became clear that the community suffered greatly from the divide introduced by Python 3. As if the core devs went in one direction while the community at large went in another.

It wasn't exactly a welcoming place for a newcomer. As if you needed to pick sides on day one. I ended up selecting another language and have never looked back.

If anything, I'm bemused that the debate still rages on years later. And I can readily picture seasoned Python users being put off by the same, and looking elsewhere for a saner ecosystem.

Case in point: As some have already hinted in the thread, the point is becoming moot nowadays, not so much because the community is slowly making the switch to Python 3, but because community members are moving en masse to Node, Go, Scala, Clojure, etc.

jordigh4• 13 years ago

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. :-/

gejjaxxita3• 13 years ago

That was opened five years ago, bizarre.

Groxx3• 13 years ago

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?

jordigh4• 13 years ago

Speed is another big concern. You want your DVCS to be as fast as possible. You don't want to wait even half a second to see the output of "hg status" just to see which files you've modified.

gejjaxxita3• 13 years ago

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.

chaosphere2112• 13 years ago

Do you mean the wall of shame/superpowers?

https://python3wos.appspot.com/

gejjaxxita3• 13 years ago

Nope, there was a graph, though that is interesting too. I'm actually quite impressed with how green it is!

rectangletangle3• 13 years ago

From a cursory glance it seems like this may be somewhat inaccurate. It states NLTK doesn't support 3, when it definitely does.

tsuraan3• 13 years ago

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• 13 years ago

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

>> list(_)

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

Wtp ?

tsuraan3• 13 years ago

Yeah, it's definitely something that can be worked around, but it's something I don't have to get around in python2, so I keep using python2. Nothing truly major, just a sticky point.

teddyh• 13 years ago

Write it as a list comprehension instead; it has identical syntax except for using square brackets instead of parentheses, and returns a list.

dded3• 13 years ago

A list comprehension would work for GP, who wants a calculator. But others like to try out snippets of code in the REPL before using them in programs, and in that case you want the code to be the same.

Would the following work? It's been a while since I've had Py3 installed, so I can't casually try it. In your PYTHONSTARTUP, place the following:

  _map = map
  def map(f, *args):
    return list(_map(f, *args))

So you get lists in interactive mode, but iterators in actual scripts.

dragonwriter2• 13 years ago

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.

rectangletangle3• 13 years ago

This. Not all generators can be converted to a list in a timely manner, seeing as infinite generators are supported.

zephjc3• 13 years ago

Consider a generator that yields results indefinitely, or even merely millions of results. Are you still sure you want those printed to the repl? :)

gizmo686• 13 years ago

That is the approach that Haskell takes. If the repl responds to ^C by aborting whatever line it was evaluating then infinite results are little more than annoying, and you quickly learn to restrict what it prints to the first few elements (in python this would just involve appending [:n]). Ultimatly this is a question of which uses you want to optimize. Personally, I find Haskell's approach more useful as a calculator.

A middle ground that I have not seen is automatically evaluating the first few elements and showing those as part of the <object> output.

reuven4• 13 years ago

The Python interactive shell could check the user's input: If it'll take infinitely long to run (e.g., an infinite generator), then it'll halt. If the code will eventually return, then it'll be run, displaying results to the user. Seems simple enough, no?

maxerickson• 13 years ago

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)

rectangletangle3• 13 years ago

You don't even have to do the assignment at the begging of your snippet. You could just refer to the builtin module explicitly.

falcolas8• 13 years ago

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]

tsuraan3• 13 years ago

You are definitely correct; it's really the combination of py3 using generators more frequently (which is a definite good thing) with the py3 repl not evaluating them that keeps me going back to py2 for my repl needs. A more fair comparison is with ghci, which expands thunks and runs IO actions when functions return them. As others have pointed out, this can be "dangerous" in the sense of flooding your console with crap (try typing [1..] in ghci; its' annoying, but not the end of the world either), but it's also really convenient when that's what you want. The python2 repl/functions do what I want, and the python3 repl/functions don't, or at least don't often enough that I keep going back to python2 for all my repl needs. Just a random chunk of anecdata, I guess.

deckiedan2• 13 years ago

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• 13 years ago

Microsoft would prefer you to use PowerShell and Visual Studio. Python wasn't invented in Redmond.

deckiedan2• 13 years ago

Yes, well, that's why I said it would be sweet of them. You know, like, a grouchy old military dad taking his daughter to see Snow White. It may not he his choice of entertainment, but it's very sweet of him to take her. :-)

Macha• 13 years ago

They did have a Python implementation for a while (IronPython)

Redoubts• 13 years ago

If anything, they would package IronPython - which wouldn't go over to well with people expecting C-extensions to work.

_random_• 13 years ago

Would be cool to include latest Mono into all major *nix distributives as well.

crag2• 13 years ago

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

falcolas8• 13 years ago

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.

rgfqeqwer2• 13 years ago

This isn't actually true anymore for many, many things:

- The major scientific/numerical packages support Python 3 (pandas, numpy, scipy).

- The best database library supports Python 3 (SQLAlchemy)

- A substantial fraction of important support libraries support Python 3 (e.g. lxml, PIL/pillow)

- Django supports Python 3

I'm honestly a little confused by people who claim that library support for 3.x "isn't there yet". My entire office has switched to Python 3 for everything.

crag2• 13 years ago

But for the newbie user it's a nightmare. If you google "Python training" you're going to get books, sites that offer training from 2.5 to 3.3. And those are recent sites (like 2012+).

Not to mention pip and package management - which compared to ruby, is just terrible. I mean there isn't even an update all command in pip. And of course if you have different versions of python you have different versions of pip. With different version of packages installed.

And now for virtualenv. Ok great tool. But even in this area there's confusion. Different people use different environment managers. And virtualenv isn't the easiest thing to setup - from a new users point of view. Where in ruby there's gem. It's installed with ruby. Period.

The community isn't doing itself any favors by dragging their feet. Everyone should jump onboard the python3 wagon. And if you need a package that isn't 3, then rewrite or look for something else. Maybe if the maintainers of said packages knew that their users weren't gonna stand for not supporting version 3 they'd get off their butts and convert - or release the code and let the community convert the package for them.

zephjc3• 13 years ago

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.

Tloewald• 13 years ago

I suspect the survey is probably selection biased towards 3 as it is. In any event, whether respondents considered it a mistake or not, it's a mistake.

comicjk• 13 years ago

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.

reuven4• 13 years ago

It's way way way higher than 50%, if my sample is accurate.

I've been teaching Python in China, Europe, Israel, and the US for years. In the last four years alone, I've taught about 2-3 Python courses (usually intro, but sometimes advanced or on specific topics) each month, at companies like Apple, Cisco, Intel, and SANDisk.

In only one case did a company ask me to teach them Python 3. The rest of them ask specifically for Python 2. In some, more advanced and unusual cases, they ask me to describe the changes that will happen in Python 3. They all have legacy code in Python 2 that they cannot imagine upgrading, mostly because there are libraries (internal or external) holding them back -- and the benefits aren't obvious.

(I should note that almost none of my courses are at startups. So it's quite possible that I'm seeing a sample of large companies, which are inherently more conservative than smaller ones.)

I thought that the survey was fine. But really, there's a problem in the whole Python 2/3 split, and while I've convinced myself over the years that people are switching, I've rarely met any of them. Which is really too bad.

njharman• 13 years ago

Why not the question "Is staying on Python 2.x a mistake?"

The whole survey is bunk. Too much misinformation and misbeliefs regarding Python 3. The only valid informed answers would be from those who've used (or used and failed) >= Py3.3 for something significant.

srobertson2• 13 years ago

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.

PythonicAlpha3• 13 years ago

No, I disagree. So many programs rely on further support for Python 2. When you would end the life of Python 2, I myself would think, if I have to make a switch, should I switch to a more reliable codebase??? (Ruby, maybe -- I don't know enough about Ruby, but I would have a look on it)

The reliability is one of Pythons strength and one of the reasons I use it. Take away the reliability and you will loose a lot. You will loose also many friends (like myself).

There was a blog post recently and stated an other option: Bring Py2 and Py3 nearer together to make the switch easier -- than more people would willingly move.

Some obstacles for moving where removed -- but a little late (e.g. the u"-Syntax was used many times in Py2 (at least outside english speaking countries or where localization is a topic) -- but abandoned in Py3. That was not necessary, but blocked an easy migration, because there are so many positions the code can be in. Now Py3 also supports the syntax and just ignores it ... why was that option not taken in the first place???) and not all. As much I know, there are still major differences when programming C extension libraries .... that makes porting existing libraries unnecessary troublesome.

Such things where not recognized early enough and still hamper adoption of Py3. Remove the blocks and you will gain more ground!

Patrick_Devine• 13 years ago

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.

DonGateley• 13 years ago

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.

ballpark• 13 years ago

It would be nice if we could see the results

bobx11• 13 years ago

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.

nixarn• 13 years ago

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

kccreator• 13 years ago

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!

analog31• 13 years ago

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.

sontek• 13 years ago

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.

sitkack2• 13 years ago

A wise man once said, http://www.aaronsw.com/weblog/python3

wheaties• 13 years ago

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.

davvid• 13 years ago

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.

janzer• 13 years ago

Results from this survey can now be found at

https://wiki.python.org/moin/2.x-vs-3.x-survey

brownbat• 13 years ago

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?

Python 2.x vs 3.x use survey

Related Stories