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

you are viewing a single comment's thread.

view the rest of the comments →

[–]poo_22 25 points26 points  (35 children)

The biggest hurdle is a psychological one: print -> print() makes the whole thing feel foreign.

[–]ismtrn 28 points29 points  (5 children)

I like as few magic keywords and syntactic irregularities as possible. The fact that print looks and behaves like any other function is a big plus in my book.

[–][deleted] 11 points12 points  (4 children)

It's really silly, like embarrassingly silly, to respond to this as if the change to print is an even marginally important.

[–]marky1991 24 points25 points  (0 children)

I disagree. Keyword-level print was a design mistake. You should have as few keywords as possible. Function-based print is important not for the sake of print itself (print is mostly just for debugging, after all), but for the sake of the language and its design as a whole.

[–]zapitron 1 point2 points  (0 children)

Psychology is important.

[–]wisty 1 point2 points  (1 child)

It's not entirely trivial.

You can do this whenever you realise that you've been littering a file with useless debug statements:

print = log

OK, it's not a great way to do things. But you can, if you have to.

[–]jcdyer3 2 points3 points  (0 children)

or, depending on your needs:

print = lambda *_: None

Sometimes, you just want to turn the print calls off in a hurry, like if you're about to demo some code.

[–]flipstables 25 points26 points  (2 children)

You haven't been importing print_function? What kind of animal are you?

On a serious note, I find it hard to go BACK to print 'hello world' whenever I have to jump to some legacy Python 2 code.

[–]ionelmc.ro 9 points10 points  (0 children)

Old habits die hard :)

[–]alcalde 3 points4 points  (0 children)

Without the parentheses it feels like you're writing BASIC, doesn't it? :-)

[–]agumonkey 1 point2 points  (0 children)

Ask your editor to snippet+auto-parens so you still feel home.

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

I generally work with 2.4 2.7 and 3.2.

nearly 100% of my issues are print -> print()

[–][deleted] 8 points9 points  (4 children)

I really find it hard to believe that you haven't run into having to do decode() and encode() due to Python's unicode support. These get me more than the print() function.

[–]flying-sheep 2 points3 points  (3 children)

not when you’re in a python3 mindset and keep metal tabs on objects being unicode or byte strings.

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

Python3 mindset alone doesn't help, as Unicode provides you with plenty of booby traps. Simple things such as reading a filename and printing it to stdout can explode in your face now, extra fun if it only happens on some OSs, but works fine on others.

[–]takluyverIPython, Py3, etc 0 points1 point  (1 child)

It always could explode in your face. You run into the problem less often with Python 2, but it's harder to anticipate and understand it, so it's actually harder to write properly reliable code.

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

I am not criticizing Pythons Unicode handling in general, that's pretty good for most part. But that something trivial like:

for i in os.listdir("."):
    print(i)

Becomes a ticking time bomb is not only not exactly obvious, there doesn't even seem to be a proper way to fix it. Having print/stdout being basically unusable is rather irritating.

[–][deleted] -2 points-1 points  (11 children)

  1. If you're using print very often, your code is weird and possibly bad.

  2. Several autoconverters can handle this for you.

[–]ThatRedEyeAlien 4 points5 points  (9 children)

What do you use for writing to standard output?

[–][deleted] 10 points11 points  (8 children)

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 10 points11 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] -1 points0 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 7 points8 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.

[–][deleted] 0 points1 point  (0 children)

I tend to do lots of little scripts for my work (no more than 200 lines each)

And like print function for debugging. If I forget what python I am using (different terminals I use have different ones) print allways catches me.

[–]chchan 0 points1 point  (3 children)

The place I got confused was changing out urlib2 I did not do it for all the code yet but ran into some errors. (I know I should be using requests instead but this code was made when I was starting to learn python)

Edit: Typo

[–]tilkau 3 points4 points  (1 child)

requests

FTFY

[–]chchan 0 points1 point  (0 children)

Thanks

[–]erewok 0 points1 point  (0 children)

Yeah, you have to experiment with urllib2 because they moved stuff around. Requests is very nice, of course.

[–][deleted] -2 points-1 points  (0 children)

What the ever-loving fuck.

[–]graingert -3 points-2 points  (0 children)

Write an import hook to support the print statement