7 ms·

The fact that Python 2 is so permissive when mixing bytes and strings I think is the fundamental reason why people think Python 3 strings are broken. In practi

The fact that Python 2 is so permissive when mixing bytes and strings I think is the fundamental reason why people think Python 3 strings are broken. In practice what happens is that Python 3 won't allow you to mix bytes and strings at all, and it will force you decode and encode properly. Python 2 will happily try to implicitly convert to and from ascii when needed. Now, this might seem simpler at the beginning because in Python 2 you require less boilerplate code, but then later, when you have to deal with a different encoding or when you use non ascii characters, you get really weird, hard to debug problems that cause real pain. Python 3's strictness is helping you preventing these kind of cases.

sheeshkebab 10y ago
Taking away permissiveness from a programming language just leads to developers not upgrade. No surprises there. Yes, Python 3's stricter model is less error prone (vs python 2 u'). the more annoying thing for me personally is the "print" function rather than previous "print" statement... Bugs the hell out of me.
- joejev 10y ago
  I hear this complaint about print all the time but I have never understood it. Why is print so special that it needs dedicated synta? Most languages don't do this and people don't seem to mind. Also, I almost never physically type print, but I do type a lot of function calls, so if anything I am more accustomed to typing it as a call.
  - TAForObvReasons 10y ago
    > Why is print so special that it needs dedicated synta? parent answered the question: > Taking away permissiveness from a programming language just leads to developers not upgrade. No surprises there. Some people used the print statement because at a time this was the recommended approach. In fact the 2.7 tutorial uses the statement: https://docs.python.org/2.7/tutorial/interpreter.html#interactive-mode https://docs.python.org/2.7/tutorial/interpreter.html#intera... print behavior was changed, and combined with the other changes and incompatible modules a lot of people decided not to jump to 3.0. Since languages like C never had a print statement to begin with -- printf was always a function call -- this issue would never have appeared in the first place.
  - kevin_thibedeau 10y ago
    The print statement is a little more convenient in the REPL. Otherwise there is little to complain about having a more consistent, extensible print without any magic. Every Py2 coder should be sticking in "from __future__ import print_function" to train themselves for the transition.
    - klibertp 10y ago
      > The print statement is a little more convenient in the REPL. IIRC ipython has a feature where you can prepend slash to any function (at the beginning of a line) to have parens inserted automatically, ie. In [0]: /print "foo" is executed as print("foo"). There - problem solved, and for all functions, not just one special case. Honestly, the crazy `print >>fileobject, "foo"` syntax is enough of a reason for removing it (print statement) from the language. It was unpythonic and I'm surprised it lasted this long in the language.
      - vram22 10y ago
        Yes, I don't like that last usage too. Non-orthogonal syntax is slightly harder to learn / remember, and the more of if there is, the more the cognitive / memory load. Of course, no language can be perfectly orthogonal or regular, though I guess Lisp comes close. (Not an expert on language design or theory.)
- sanderjd 10y ago
  > Taking away permissiveness from a programming language just leads to developers not upgrade. The longer I do this, the more I see non-permissiveness in data validation as a feature and am actively happy to upgrade to get it. Ruby fixed their strings in 1.9 and it was one of the main reasons I was excited to upgrade our codebase to it. It was a pain to upgrade, but we found some real bugs, and were very happy with it after the fact. That the Python community has not embraced this yet completely mystifies me. Maybe you're right about permissiveness if you're talking about syntax, but even then, I hate permissive syntax that increases ambiguity.
- vram22 10y ago
  Whatever the other pros and cons of the print statement might be, one potential advantage of the function version of print, is that you can pass it to a function as an argument (call it the "output function" argument), and on other calls, substitute some other function in its place, which could do anything, like maybe output to a network connection, or to a file instead. Basically, a polymorphic parameter, which, based on the actual function value passed to it, might do one of a number of different but related things (all being some form of "output"). Like Python's file-like objects protocol, where you can pass any object that implements file-like functions/methods in a place where an actual file object arg is expected. Duck typing, IOW. I realize this could also be done with the statement version of print, just by wrapping it in a function, using args, *kwargs, but it seems like the function version would be easier to use for this. Of course, you would have to take care that all the functions you plan to pass to it, such as print and others, can do whatever is wanted to be done with it in the called code.
- njharman 10y ago
  print function is so superior than print statement. I use to (long ago like v1.5 or 2.0) create stupid little functions that put print into a function (also raise and some other statements cause it's super fucking annoying that some language elements can't be used in expression context) or use sys.stdout.write() and get pissed off cause that doesn't auto append newline. print (and I'd argue raise) aren't special enough to be statements, to have special syntactical rules, to be so special cause that works different.
  - Groxx 10y ago
    Raise I might argue in favor of (though I find it annoying too) solely because it's a language feature to change where you return to. It's not a thing you can express via other code. (though a callback-only language sounds kinda interesting / terrifying) Print statements are horrific though, totally agreed. It's just normal IO with a common default, but making it as a statement causes problems, e.g. `lambda: print 'yay'` isn't allowed.
emperorcezar 10y ago
Keeping bytes and strings separated is actually the simpler situation. What it is not, is easy, because it takes a little bit of learning. Sadly many people prefer easy over simple.
- ageofwant 10y ago
  It is only hard if you used it like that before. I'm betting people that come directly to Python 3.5 will find the difference blatantly obvious. I remember many years ago, coming from C++ boost's String that I was taken aback about Python's laissez-faire approach to strings. Python 3 fixes that.
  - witty_username 10y ago
    5 years ago I started learning programming with Python 3.0 and Python 2 just seems like Python 3 + many warts and lack of new features. EDIT: changed phrasing
    - kqr 10y ago
      Could you recommend a learning resource for Python 5? I also tried learning it years ago but eventually went back to 3.0.
      - witty_username 10y ago
        Whoops, the phrasing was a bit ambiguous. See the new edited comment.

sheeshkebab 10y ago

Taking away permissiveness from a programming language just leads to developers not upgrade. No surprises there. Yes, Python 3's stricter model is less error prone (vs python 2 u'). the more annoying thing for me personally is the "print" function rather than previous "print" statement... Bugs the hell out of me.

joejev 10y ago
I hear this complaint about print all the time but I have never understood it. Why is print so special that it needs dedicated synta? Most languages don't do this and people don't seem to mind. Also, I almost never physically type print, but I do type a lot of function calls, so if anything I am more accustomed to typing it as a call.
- TAForObvReasons 10y ago
  > Why is print so special that it needs dedicated synta? parent answered the question: > Taking away permissiveness from a programming language just leads to developers not upgrade. No surprises there. Some people used the print statement because at a time this was the recommended approach. In fact the 2.7 tutorial uses the statement: https://docs.python.org/2.7/tutorial/interpreter.html#interactive-mode https://docs.python.org/2.7/tutorial/interpreter.html#intera... print behavior was changed, and combined with the other changes and incompatible modules a lot of people decided not to jump to 3.0. Since languages like C never had a print statement to begin with -- printf was always a function call -- this issue would never have appeared in the first place.
- kevin_thibedeau 10y ago
  The print statement is a little more convenient in the REPL. Otherwise there is little to complain about having a more consistent, extensible print without any magic. Every Py2 coder should be sticking in "from __future__ import print_function" to train themselves for the transition.
  - klibertp 10y ago
    > The print statement is a little more convenient in the REPL. IIRC ipython has a feature where you can prepend slash to any function (at the beginning of a line) to have parens inserted automatically, ie. In [0]: /print "foo" is executed as print("foo"). There - problem solved, and for all functions, not just one special case. Honestly, the crazy `print >>fileobject, "foo"` syntax is enough of a reason for removing it (print statement) from the language. It was unpythonic and I'm surprised it lasted this long in the language.
    - vram22 10y ago
      Yes, I don't like that last usage too. Non-orthogonal syntax is slightly harder to learn / remember, and the more of if there is, the more the cognitive / memory load. Of course, no language can be perfectly orthogonal or regular, though I guess Lisp comes close. (Not an expert on language design or theory.)
sanderjd 10y ago
> Taking away permissiveness from a programming language just leads to developers not upgrade. The longer I do this, the more I see non-permissiveness in data validation as a feature and am actively happy to upgrade to get it. Ruby fixed their strings in 1.9 and it was one of the main reasons I was excited to upgrade our codebase to it. It was a pain to upgrade, but we found some real bugs, and were very happy with it after the fact. That the Python community has not embraced this yet completely mystifies me. Maybe you're right about permissiveness if you're talking about syntax, but even then, I hate permissive syntax that increases ambiguity.
vram22 10y ago
Whatever the other pros and cons of the print statement might be, one potential advantage of the function version of print, is that you can pass it to a function as an argument (call it the "output function" argument), and on other calls, substitute some other function in its place, which could do anything, like maybe output to a network connection, or to a file instead. Basically, a polymorphic parameter, which, based on the actual function value passed to it, might do one of a number of different but related things (all being some form of "output"). Like Python's file-like objects protocol, where you can pass any object that implements file-like functions/methods in a place where an actual file object arg is expected. Duck typing, IOW. I realize this could also be done with the statement version of print, just by wrapping it in a function, using args, *kwargs, but it seems like the function version would be easier to use for this. Of course, you would have to take care that all the functions you plan to pass to it, such as print and others, can do whatever is wanted to be done with it in the called code.
njharman 10y ago
print function is so superior than print statement. I use to (long ago like v1.5 or 2.0) create stupid little functions that put print into a function (also raise and some other statements cause it's super fucking annoying that some language elements can't be used in expression context) or use sys.stdout.write() and get pissed off cause that doesn't auto append newline. print (and I'd argue raise) aren't special enough to be statements, to have special syntactical rules, to be so special cause that works different.
- Groxx 10y ago
  Raise I might argue in favor of (though I find it annoying too) solely because it's a language feature to change where you return to. It's not a thing you can express via other code. (though a callback-only language sounds kinda interesting / terrifying) Print statements are horrific though, totally agreed. It's just normal IO with a common default, but making it as a statement causes problems, e.g. `lambda: print 'yay'` isn't allowed.

emperorcezar 10y ago

Keeping bytes and strings separated is actually the simpler situation. What it is not, is easy, because it takes a little bit of learning. Sadly many people prefer easy over simple.

ageofwant 10y ago
It is only hard if you used it like that before. I'm betting people that come directly to Python 3.5 will find the difference blatantly obvious. I remember many years ago, coming from C++ boost's String that I was taken aback about Python's laissez-faire approach to strings. Python 3 fixes that.
- witty_username 10y ago
  5 years ago I started learning programming with Python 3.0 and Python 2 just seems like Python 3 + many warts and lack of new features. EDIT: changed phrasing
  - kqr 10y ago
    Could you recommend a learning resource for Python 5? I also tried learning it years ago but eventually went back to 3.0.
    - witty_username 10y ago
      Whoops, the phrasing was a bit ambiguous. See the new edited comment.