Earlier quoted context omitted.
I think people would prefer "from __past__ import print_statement" in 3.x.
Why the hell?
I would hazard a guess that it is because the statement allows for easily adding a `print varname` in your code while debugging.
Python 2.x vs 3.x use survey
21–30 of 119 posts
Re: Python 2.x vs 3.x use survey
#22The 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...
Write it as a list comprehension instead; it has identical syntax except for using square brackets instead of parentheses, and returns a list.
Re: Python 2.x vs 3.x use survey
#23Missing 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 prefer it as well. Being able to do things like throw
print() or
Re: Python 2.x vs 3.x use survey
#24Earlier quoted context omitted.
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.
The inability to use string manipulation functions on bytestrings without converting them to unicode and back for each operation.
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?
Re: Python 2.x vs 3.x use survey
#25"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.
Re: Python 2.x vs 3.x use survey
#26Missing 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.
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?
Re: Python 2.x vs 3.x use survey
#27The 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...
> 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.
Re: Python 2.x vs 3.x use survey
#28Re: Python 2.x vs 3.x use survey
#29Earlier quoted context omitted.
I would hazard a guess that it is because the statement allows for easily adding a `print varname` in your code while debugging.
It's two extra chars to write print(varname). One if your editor auto-inserts matching parens!
Since the space is replaced by the first paren, it's either 0 or 1 more chars :)
Re: Python 2.x vs 3.x use survey
#30Earlier quoted context omitted.
Why the hell?
I would hazard a guess that it is because the statement allows for easily adding a `print varname` in your code while debugging.
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.