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. :-/
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?
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.
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.
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.
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.
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.
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.
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.
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...
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...
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:
> 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.
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)
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.)
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.
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.
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.
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.
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?
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?
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.
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.
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.
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?
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.
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.
[+] [-] jordigh|12 years ago|reply
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
[+] [-] Groxx|12 years ago|reply
[+] [-] crag|12 years ago|reply
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
Ultimately, you did pro-Python 3 supporters a disservice by not speaking up.
[+] [-] comicjk|12 years ago|reply
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
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
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 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
[+] [-] deckiedan|12 years ago|reply
[+] [-] xradionut|12 years ago|reply
[+] [-] _random_|12 years ago|reply
[+] [-] tsuraan|12 years ago|reply
[+] [-] bluecalm|12 years ago|reply
>>> 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
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
[+] [-] maxerickson|12 years ago|reply
The override is easy:
(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
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] zephjc|12 years ago|reply
[+] [-] nixarn|12 years ago|reply
[+] [-] ddebernardy|12 years ago|reply
[+] [-] falcolas|12 years ago|reply
I say this as someone still on Python 2.6 due to environment restrictions.
[+] [-] dec0dedab0de|12 years ago|reply
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
[+] [-] Kliment|12 years ago|reply
[+] [-] viraptor|12 years ago|reply
[+] [-] wonjohnchoi|12 years ago|reply
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
[+] [-] infocollector|12 years ago|reply
[+] [-] analog31|12 years ago|reply
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
[+] [-] davvid|12 years ago|reply
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|12 years ago|reply
https://wiki.python.org/moin/2.x-vs-3.x-survey
[+] [-] sitkack|12 years ago|reply
[+] [-] brownbat|12 years ago|reply
[+] [-] sontek|12 years ago|reply
Before PyCon SurveyMonkey(my employer) will be deploying a major part of our application on Python3.
[+] [-] kccreator|12 years ago|reply
But I'm fascinated by the debates over the merits of the two. Thanks for posting the survey!
[+] [-] gejjaxxita|12 years ago|reply
[+] [-] chaosphere2112|12 years ago|reply
https://python3wos.appspot.com/
[+] [-] wheaties|12 years ago|reply
[+] [-] winstonian|12 years ago|reply
[deleted]