20 ms·

Python 2.x vs 3.x use survey

104 points by janzer 13y ago

dec0dedab0de 13y 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.
- viraptor 13y 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)
  - sp332 13y ago
    I think people would prefer "from __past__ import print_statement" in 3.x.
    - d0vs 13y ago
      Why the hell?
      - sp332 13y ago
        I don't know, but it bugs people. https://news.ycombinator.com/item?id=6987309 https://news.ycombinator.com/item?id=6987309 https://news.ycombinator.com/item?id=6985792 https://news.ycombinator.com/item?id=6985792
      - trwired 13y ago
        I would hazard a guess that it is because the statement allows for easily adding a `print varname` in your code while debugging.
        randlet 13y ago
        It's two extra chars to write print(varname). One if your editor auto-inserts matching parens!
        sp332 13y ago
        Since the space is replaced by the first paren, it's either 0 or 1 more chars :)
        Shish2k 13y ago
        Shift-9 is more fiddly to type than space though :P
        dragonwriter 13y ago
        print(varname) is one extra keystroke -- and a whole more convenient than a statement when you want to do it in a lambda for debugging.
    - viraptor 13y ago
      That's why I'm asking really - not only those two would be pretty much equivalent, there's really nothing that can be expressed with one, but not the other. I mean that's kind of like saying "would you use it if they called the binary snake instead of python3" - what's the reason apart from personal preference for the syntax?
- Kliment 13y 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?
  - viraptor 13y 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.
    - Kliment 13y ago
      The inability to use string manipulation functions on bytestrings without converting them to unicode and back for each operation.
      - viraptor 13y ago
        What do you mean by "string manipulation"? bytes are not text strings. If you actually mean text operations, then converting them is something you should also do in py2. Edit: now that I thought about it - since you're able to decode the bytes you're using, it means you are operating on text - why not convert it then?
        Kliment 13y ago
        See http://bugs.python.org/issue3982 http://bugs.python.org/issue3982 that's linked elsewhere in these comments for the kind of things that don't work on bytestrings
        Borogove 13y ago
        As many comments in that thread point out, byte arrays are not strings, and casually conflating or implicitly converting the two is terrible mental hygiene. Explicit is better than implicit.
- dded 13y 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 13y 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 13y 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?
  - zephjc 13y 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)
    - falcolas 13y ago
      FWIW: pprint = functools.partial(print, end=' ') pprint('hi') do_something() print('there') print('hi', 'there', sep=' ') I appreciate the fine grained control, and the ability to do things like `functools.partial` on it. fprint = functools.partial(print, file='/var/log/foo.log') fprint("I'm writing to a file!") fprint("So am I")
      - Fede_V 13y ago
        I understand this, but couldn't you simply wrap print itself in a function, and do that in Python 2.7 already? Granted, your method saves you one line and it's more 'natural'.
        falcolas 13y ago
        Not really, since the Python 2 version is a keyword, and not a function, you can't simply provide keyword arguments to it. You would instead have to build up a string and eval it. It would have to be something like this (completely untested): def print_wrapper(*args, **kwargs) outfile = None print_stmt = "print " if 'file' in kwargs: outfile = open(kwargs['file'], 'a') print_stmt += '>>outfile ' print_stmt += ", ".join(*args) if 'end' in kwargs and kwargs['end'] == ' ': print_stmt += ',' eval(print_stmt) if outfile is not None: outfile.close() sep and other end values for anything other than ' ' would not be possible. http://docs.python.org/2.6/reference/simple_stmts.html#the-print-statement http://docs.python.org/2.6/reference/simple_stmts.html#the-p...
infocollector 13y ago
Where are the real-time results? :)
ddebernardy 13y 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.
- falcolas 13y 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.
  - stefantalpalaru 13y 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.
    - falcolas 13y ago
      What language would you recommend, that would have a similar jump in syntax, and still give you more speed and resolve memory usage? Go? Go is painfully statically typed (painful example: requiring you to cast an int to float32 to do a `>` or `<` operation) and feels a lot more like writing C than Python (not to mention its lack in the "batteries included" department). Ruby? Same speed and memory "problems" as Python. Perl? Faster, but its language design philosophy is diametrically opposed to that of Python. Clojure/Haskel? Syntax and program structure are so radically different from Python there's no comparing them to Python3 when discussing differences from Python2.
      - maxk42 13y ago
        I would actually pick Go. Yes, the strong static typing is a pain in the ass, but the rules are simple and regular. It's easy to understand and implement. The same cannot be said for the multitude of changes to Python.
jordigh 13y ago
For Mercurial, this is the biggest problem with Python 3: http://bugs.python.org/issue3982 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 13y ago
  That was opened five years ago, bizarre.
- Groxx 13y 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?
  - jordigh 13y 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.
    - Groxx 13y ago
      Mercurial is a big project. Surely there's one skilled C programmer who could write a relatively-portable, efficient, limited version of this feature (or find one, I assume something extremely similar exists in several flavors). Once that's done, have a Python fallback for those esoteric systems where it doesn't work, and move on with life. Since it's apparently a critical code-path, that's normal development for great performance. I could easily be underestimating the difficulty of integrating C with Python - I've never done it personally, but I gather that's one of its strengths. But this seems like a pretty simple problem, which has a pretty simple implementation in any language (there's an included Python implementation on the linked page, ~20 LOC?), and if it's a critical performance piece it's surely worth the cost to make that piece.
gejjaxxita 13y 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 13y ago
  Do you mean the wall of shame/superpowers? https://python3wos.appspot.com/ https://python3wos.appspot.com/
  - gejjaxxita 13y ago
    Nope, there was a graph, though that is interesting too. I'm actually quite impressed with how green it is!
  - rectangletangle 13y ago
    From a cursory glance it seems like this may be somewhat inaccurate. It states NLTK doesn't support 3, when it definitely does.
    - walrus 13y ago
      The NLTK site says the Python 3 version is still alpha.
tsuraan 13y 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 13y 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)) <map object at 0x02DDDB90> >>> list(_) [1, 4, 9, 16, 25, 36, 49, 64, 81] Wtp ?
  - tsuraan 13y 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 13y ago
  Write it as a list comprehension instead; it has identical syntax except for using square brackets instead of parentheses, and returns a list.
  - dded 13y 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.
- 13y ago
deckiedan 13y 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 13y ago
  Microsoft would prefer you to use PowerShell and Visual Studio. Python wasn't invented in Redmond.
  - deckiedan 13y 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 13y ago
    They did have a Python implementation for a while (IronPython)
  - Redoubts 13y ago
    If anything, they would package IronPython - which wouldn't go over to well with people expecting C-extensions to work.
- _random_ 13y ago
  Would be cool to include latest Mono into all major *nix distributives as well.
crag 13y 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.
- falcolas 13y 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.
  - rgfqeqwer 13y 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.
    - shadowmint 13y ago
      oh please. one single dependency that doesn't support py3 is the death knell to using it for anything, EVER I use python daily at work and you can be safely assured the state of py3 on pypi is fu$$$$ed. (we use pyramid not django for what it's worth)
      - kbenson 13y ago
        one single dependency that doesn't support py3 is the death knell to using it for anything, EVER Can't you logically extend that across language boundaries, and if so, why would you ever try to use a different language? A needed library or feature of a library might be missing. Is it really that hard to take whatever dependency isn't supported and patch it? Isn't that one of the benefits of running an interpreted language?
ballpark 13y ago
It would be nice if we could see the results
bobx11 13y 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 13y 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 13y 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!
winstonian 13y ago
For me, the changes introduced in Python 3 make sense... And I like the new changes--even the print function. However, my only gripe with it was a recent experience while I was teaching Python to a kid I'm mentoring. I sent him a link this Python Book: http://inventwithpython.com/chapters/ http://inventwithpython.com/chapters/ It's written in Python 3. Not a huge deal, but it introduced some confusion right from the start (having to install Python 3 instead of Python 2 because he was running into compatibility issues). Learning programming is confusing/challenging by itself. I imagine he's going to run into difficulty very early on while Googling for help and finds threads on Stack Overflow that were written in Python 2. I think an important and overlooked issue is that one of Python's strengths is that it's recommended as a great first language. I think learning Python 2 still is; but starting with Python 3 may likely lead to a lot of backwards compatibility issues and make it frustrating for beginners, or at least force them to constantly translate instructions written in Python 2 to Python 3 in their head.
analog31 13y 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 13y 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.
sitkack 13y ago
A wise man once said, http://www.aaronsw.com/weblog/python3 http://www.aaronsw.com/weblog/python3
wheaties 13y 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 13y 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 13y ago
Results from this survey can now be found at https://wiki.python.org/moin/2.x-vs-3.x-survey https://wiki.python.org/moin/2.x-vs-3.x-survey
brownbat 13y 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?

104 points by janzer 13y 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.

viraptor 13y 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)
- sp332 13y ago
  I think people would prefer "from __past__ import print_statement" in 3.x.
  - d0vs 13y ago
    Why the hell?
    - sp332 13y ago
      I don't know, but it bugs people. https://news.ycombinator.com/item?id=6987309 https://news.ycombinator.com/item?id=6987309 https://news.ycombinator.com/item?id=6985792 https://news.ycombinator.com/item?id=6985792
    - trwired 13y ago
      I would hazard a guess that it is because the statement allows for easily adding a `print varname` in your code while debugging.
      - randlet 13y ago
        It's two extra chars to write print(varname). One if your editor auto-inserts matching parens!
        sp332 13y ago
        Since the space is replaced by the first paren, it's either 0 or 1 more chars :)
        Shish2k 13y ago
        Shift-9 is more fiddly to type than space though :P
      - dragonwriter 13y ago
        print(varname) is one extra keystroke -- and a whole more convenient than a statement when you want to do it in a lambda for debugging.
  - viraptor 13y ago
    That's why I'm asking really - not only those two would be pretty much equivalent, there's really nothing that can be expressed with one, but not the other. I mean that's kind of like saying "would you use it if they called the binary snake instead of python3" - what's the reason apart from personal preference for the syntax?
Kliment 13y 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?
- viraptor 13y 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.
  - Kliment 13y ago
    The inability to use string manipulation functions on bytestrings without converting them to unicode and back for each operation.
    - viraptor 13y ago
      What do you mean by "string manipulation"? bytes are not text strings. If you actually mean text operations, then converting them is something you should also do in py2. Edit: now that I thought about it - since you're able to decode the bytes you're using, it means you are operating on text - why not convert it then?
      - Kliment 13y ago
        See http://bugs.python.org/issue3982 http://bugs.python.org/issue3982 that's linked elsewhere in these comments for the kind of things that don't work on bytestrings
        Borogove 13y ago
        As many comments in that thread point out, byte arrays are not strings, and casually conflating or implicitly converting the two is terrible mental hygiene. Explicit is better than implicit.
dded 13y 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 13y 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 13y 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?
- zephjc 13y 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)
  - falcolas 13y ago
    FWIW: pprint = functools.partial(print, end=' ') pprint('hi') do_something() print('there') print('hi', 'there', sep=' ') I appreciate the fine grained control, and the ability to do things like `functools.partial` on it. fprint = functools.partial(print, file='/var/log/foo.log') fprint("I'm writing to a file!") fprint("So am I")
    - Fede_V 13y ago
      I understand this, but couldn't you simply wrap print itself in a function, and do that in Python 2.7 already? Granted, your method saves you one line and it's more 'natural'.
      - falcolas 13y ago
        Not really, since the Python 2 version is a keyword, and not a function, you can't simply provide keyword arguments to it. You would instead have to build up a string and eval it. It would have to be something like this (completely untested): def print_wrapper(*args, **kwargs) outfile = None print_stmt = "print " if 'file' in kwargs: outfile = open(kwargs['file'], 'a') print_stmt += '>>outfile ' print_stmt += ", ".join(*args) if 'end' in kwargs and kwargs['end'] == ' ': print_stmt += ',' eval(print_stmt) if outfile is not None: outfile.close() sep and other end values for anything other than ' ' would not be possible. http://docs.python.org/2.6/reference/simple_stmts.html#the-print-statement http://docs.python.org/2.6/reference/simple_stmts.html#the-p...

infocollector 13y ago

Where are the real-time results? :)

ddebernardy 13y 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.

falcolas 13y 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.
- stefantalpalaru 13y 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.
  - falcolas 13y ago
    What language would you recommend, that would have a similar jump in syntax, and still give you more speed and resolve memory usage? Go? Go is painfully statically typed (painful example: requiring you to cast an int to float32 to do a `>` or `<` operation) and feels a lot more like writing C than Python (not to mention its lack in the "batteries included" department). Ruby? Same speed and memory "problems" as Python. Perl? Faster, but its language design philosophy is diametrically opposed to that of Python. Clojure/Haskel? Syntax and program structure are so radically different from Python there's no comparing them to Python3 when discussing differences from Python2.
    - maxk42 13y ago
      I would actually pick Go. Yes, the strong static typing is a pain in the ass, but the rules are simple and regular. It's easy to understand and implement. The same cannot be said for the multitude of changes to Python.

jordigh 13y ago

For Mercurial, this is the biggest problem with Python 3: http://bugs.python.org/issue3982 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 13y ago
That was opened five years ago, bizarre.
Groxx 13y 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?
- jordigh 13y 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.
  - Groxx 13y ago
    Mercurial is a big project. Surely there's one skilled C programmer who could write a relatively-portable, efficient, limited version of this feature (or find one, I assume something extremely similar exists in several flavors). Once that's done, have a Python fallback for those esoteric systems where it doesn't work, and move on with life. Since it's apparently a critical code-path, that's normal development for great performance. I could easily be underestimating the difficulty of integrating C with Python - I've never done it personally, but I gather that's one of its strengths. But this seems like a pretty simple problem, which has a pretty simple implementation in any language (there's an included Python implementation on the linked page, ~20 LOC?), and if it's a critical performance piece it's surely worth the cost to make that piece.

gejjaxxita 13y 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 13y ago
Do you mean the wall of shame/superpowers? https://python3wos.appspot.com/ https://python3wos.appspot.com/
- gejjaxxita 13y ago
  Nope, there was a graph, though that is interesting too. I'm actually quite impressed with how green it is!
- rectangletangle 13y ago
  From a cursory glance it seems like this may be somewhat inaccurate. It states NLTK doesn't support 3, when it definitely does.
  - walrus 13y ago
    The NLTK site says the Python 3 version is still alpha.

tsuraan 13y 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 13y 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)) <map object at 0x02DDDB90> >>> list(_) [1, 4, 9, 16, 25, 36, 49, 64, 81] Wtp ?
- tsuraan 13y 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 13y ago
Write it as a list comprehension instead; it has identical syntax except for using square brackets instead of parentheses, and returns a list.
- dded 13y 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.
13y ago

deckiedan 13y 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 13y ago
Microsoft would prefer you to use PowerShell and Visual Studio. Python wasn't invented in Redmond.
- deckiedan 13y 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 13y ago
  They did have a Python implementation for a while (IronPython)
- Redoubts 13y ago
  If anything, they would package IronPython - which wouldn't go over to well with people expecting C-extensions to work.
_random_ 13y ago
Would be cool to include latest Mono into all major *nix distributives as well.

crag 13y 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.

falcolas 13y 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.
- rgfqeqwer 13y 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.
  - shadowmint 13y ago
    oh please. one single dependency that doesn't support py3 is the death knell to using it for anything, EVER I use python daily at work and you can be safely assured the state of py3 on pypi is fu$$$$ed. (we use pyramid not django for what it's worth)
    - kbenson 13y ago
      one single dependency that doesn't support py3 is the death knell to using it for anything, EVER Can't you logically extend that across language boundaries, and if so, why would you ever try to use a different language? A needed library or feature of a library might be missing. Is it really that hard to take whatever dependency isn't supported and patch it? Isn't that one of the benefits of running an interpreted language?

ballpark 13y ago

It would be nice if we could see the results

bobx11 13y 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 13y 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 13y 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!

winstonian 13y ago

For me, the changes introduced in Python 3 make sense... And I like the new changes--even the print function. However, my only gripe with it was a recent experience while I was teaching Python to a kid I'm mentoring. I sent him a link this Python Book: http://inventwithpython.com/chapters/ http://inventwithpython.com/chapters/ It's written in Python 3. Not a huge deal, but it introduced some confusion right from the start (having to install Python 3 instead of Python 2 because he was running into compatibility issues). Learning programming is confusing/challenging by itself. I imagine he's going to run into difficulty very early on while Googling for help and finds threads on Stack Overflow that were written in Python 2. I think an important and overlooked issue is that one of Python's strengths is that it's recommended as a great first language. I think learning Python 2 still is; but starting with Python 3 may likely lead to a lot of backwards compatibility issues and make it frustrating for beginners, or at least force them to constantly translate instructions written in Python 2 to Python 3 in their head.

analog31 13y 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 13y 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.

sitkack 13y ago

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

wheaties 13y 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 13y 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 13y ago

Results from this survey can now be found at https://wiki.python.org/moin/2.x-vs-3.x-survey https://wiki.python.org/moin/2.x-vs-3.x-survey

brownbat 13y 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?