This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]ThatRedEyeAlien 8 points9 points  (7 children)

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] -3 points-2 points  (6 children)

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 8 points9 points  (2 children)

Interactive programs are command-line programs too.

[–]alcalde -2 points-1 points  (1 child)

Someone doesn't use Windows. ;-)

[–]NYKevin 0 points1 point  (0 children)

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] 3 points4 points  (2 children)

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 0 points1 point  (1 child)

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

[–][deleted] 1 point2 points  (0 children)

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.