261–264 of 264 posts
Earlier quoted context omitted.
Why do your users care about symbols internal to your code?
They don't, they care about `str` being unicode and developers not having to do additional work to support unicode strings.
Earlier quoted context omitted.
"11. There should be one-- and preferably only one --obvious way to do it." from the Zen of Python. Somebody intentionally misread it as, "There should be only one way to do it." They obviously made a grave mistake. Same with many 2->3 changes.
Also from the Zen of Python: "Special cases aren't special enough to break the rules", the old print statement contains a lot of special syntax not found anywhere else in the language. Also "Readability counts", it's really obvious what print("foo", file=sys.stderr, end="") does instead of deciphering a construct like print >>sys.stderr, "foo", . Moreover you can pass a print function around, perform partial applicat…
Earlier quoted context omitted.
Also from the Zen of Python: "Special cases aren't special enough to break the rules", the old print statement contains a lot of special syntax not found anywhere else in the language. Also "Readability counts", it's really obvious what print("foo", file=sys.stderr, end="") does instead of deciphering a construct like print >>sys.stderr, "foo", . Moreover you can pass a print function around, perform partial applicat…
You prove nothing about why the two cannot co-exist in a non-regressive way. 'print' as a function already exists in Python 2, providing all the benefits you describe.
Earlier quoted context omitted.
They don't, they care about `str` being unicode and developers not having to do additional work to support unicode strings.
Python 3 has, more or less, just renamed unicode() to str() and str() to bytes(). unicode() support was already complete in Python 2. The rename is not a user-facing feature.