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(<SOMETHING I'M TRYING TO DEBUG>) or

into a lambda has been useful on multiple occasions.

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'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?

See http://bugs.python.org/issue3982 that's linked elsewhere in these comments for the kind of things that don't work on bytestrings

I read it all, and to be honest I think I agree the most with http://bugs.python.org/issue3982#msg180441 (.format may be making some things simpler, but it goes against the idea of well separated bytes -vs- text)

But really, I just don't like how http/ftp/similar protocols were designed in the first place. They're mixing binary and text in the same stream. That's ugly and when you have strict rules about text encoding in your language, the implementation also turns out ugly - what a surprise :)

As many comments in that thread point out, byte arrays are not strings, and casually conflating or implicitly converting the two is terrible mental hygiene.

Explicit is better than implicit.

Is there some story behind it? It looks like the smallest issue out of the whole migration. (especially with from __future__ import print_function)

I think people would prefer "from __past__ import print_statement" in 3.x.

That's why I'm asking really - not only those two would be pretty much equivalent, there's really nothing that can be expressed with one, but not the other. I mean that's kind of like saying "would you use it if they called the binary snake instead of python3" - what's the reason apart from personal preference for the syntax?

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.

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

Shift-9 is more fiddly to type than space though :P

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.

I don't know, but it bugs people. https://news.ycombinator.com/item?id=6987309 https://news.ycombinator.com/item?id=6985792

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?

no trailing space is a convenient shorthand - print by itself prints with a newline (so it might make sense to have print() vs println()); print + comma omits the newline and waits for the next print statement, so that

    print 'hi',
    do_something()
    print 'there'

and

    print 'hi', 'there'

both yield

    hi there

(Assuming do_something() doesn't call print itself)

FWIW:

    pprint = functools.partial(print, end=' ')
    pprint('hi')
    do_something()
    print('there')

    print('hi', 'there', sep=' ')

I appreciate the fine grained control, and the ability to do things like `functools.partial` on it.

    fprint = functools.partial(print, file='/var/log/foo.log')
    fprint("I'm writing to a file!")
    fprint("So am I")

I understand this, but couldn't you simply wrap print itself in a function, and do that in Python 2.7 already? Granted, your method saves you one line and it's more 'natural'.

Not really, since the Python 2 version is a keyword, and not a function, you can't simply provide keyword arguments to it. You would instead have to build up a string and eval it. It would have to be something like this (completely untested):

    def print_wrapper(*args, **kwargs)
        outfile = None
        print_stmt = "print "
        if 'file' in kwargs:
            outfile = open(kwargs['file'], 'a')
            print_stmt += '>>outfile '
        print_stmt += ", ".join(*args)
        if 'end' in kwargs and kwargs['end'] == ' ':
            print_stmt += ','
        eval(print_stmt)
        if outfile is not None: outfile.close()

sep and other end values for anything other than ' ' would not be possible.

http://docs.python.org/2.6/reference/simple_stmts.html#the-p...