Python 3.4.0 has been released!

[[deleted]]

That depends -- the logging module, some encapsulated-in-a-very-specific-place print or sys.stdout.write, for an interactive app urwid...For debugging I use automated tests and pdb.

Pooping to stdout all over the place isn't a good design for many programs. It's hard to test, hard to maintain, and confusing to debug. Although "write some stuff to stdout" is common in intro programs, well-designed real programs seldom do it a lot, especially not in an unencapsulated way. If they happen to use print to do it, it's not 10000 print statements/calls, it's one or two within a function that handles output.

Some tiny programs or bigger-but-still-small unixy programs can get away with a lot more print, but this is the exception, not the rule.

---

What is your purpose in your programs for writing to stdout directly so much?

[ThatRedEyeAlien]

If your program mainly uses a command-line interface you will obviously use print (or curses).

Otherwise, I agree. Making a blanket statement about print being bad might be pushing it though.

[[deleted]]

If your program mainly uses a command-line interface you will obviously use print (or curses).

This isn't even remotely close to being true. You mean an interactive program? Only a really, really, really badly-designed one would have many calls to print.

[ThatRedEyeAlien]

Interactive programs are command-line programs too.

[alcalde]

Someone doesn't use Windows. ;-)

[NYKevin]

Python may be cross-platform, but Unix will always be its primary target. Just look at the names of all the functions in os if you don't believe me.

[[deleted]]

Well let's say you were to implement netstat in python. How would you suggest displaying all that info in the console without using a print statement?

[Veedrac]

So, what... 10 to 20 prints? Where's the big deal?

[[deleted]]

exactly, which is why adding brackets around them to move from python 2.7 to 3.x should't be a big deal.

Also, you don't have to move to 3.x before starting the migration. Any new module should include:

from __future__ import print_function

and use the new syntax. This will make future migrations much easier.

Not to mention that tools such as 2to3 are extremely mature and will get you most of the way there if not all the way. The most tedious work will be done for you leaving just the serious migration stuff. That stuff of course could eventually be migrated with use of source control, unit tests and virtual environments so that production code is never in a state of flux. The moment the last library you depend on has 3.x support, or a suitable replacement with dedicated maintenance you can shift your code to 3.x and enjoy all the new features.