Hacker News Reader

Comment by ceronman | Hacker News Reader

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.

View on HN

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.

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.

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

Could you recommend a learning resource for Python 5? I also tried learning it years ago but eventually went back to 3.0.

Whoops, the phrasing was a bit ambiguous. See the new edited comment.

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.

> 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.

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.

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.

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.

> 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.

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.)

> 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#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.

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.

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.

Reply on news.ycombinator.com