Python is going to be hard

Steven D'Aprano steve+comp.lang.python at
Thu Sep 4 15:25:39 CEST 2014

Chris Angelico wrote:

> On Thu, Sep 4, 2014 at 12:10 PM, Rustom Mody <rustompmody at>
> wrote:
>> On Thursday, September 4, 2014 7:26:56 AM UTC+5:30, Chris Angelico wrote:
>>> On Thu, Sep 4, 2014 at 11:48 AM, Rustom Mody wrote:
>>> >>>> NO PRINT
>>> Why are you so dead against print?
>> Because it heralds a typical noob code-smell
>> [especially  when the OP admits that BASIC is his background]
> And, of course, all those lovely Unix programs that produce output on
> stdout, they're full of code smell too, right? I don't care what
> someone's background is; console output is *not* code smell.

I cautiously agree with Rustom on this one. Of course console output is
often useful, but it is slightly smelly:

- beginners have a tendency to use print when they should be using
  return, and consequently can't easily chain functions together;

- languages like shell scripting languages, which are designed to
  chain such printing functions together, suffer because of it:

  * they're less efficient, due to having to convert to and 
    from text repeatedly; 

  * as a programming language, they're rather impoverished,
    even if they have internal data types which aren't text,
    they can't pass output to other programs except as text;

    (very occasionally, they support a hybrid "text separated
    by NUL bytes" mode)

  * they tend to be rather less resilient since they cannot 
    easily separate presentation from calculation; any change
    to the presentation, or unexpected presentation, is likely
    to break your code silently.

Think of how many broken bash scripts there are out there which assume that
files names can never contain newlines. Or, for that matter, spaces.

Even in Python, consider how limiting something like dis.dis() is, seeing
how it prints its output instead of returning it.

> Anyway, all you're doing is relying on the magic of interactive mode
> to call repr() and print() for you.

Well, yes, but isn't that the point? Let your tools do most of the work.

>> The interpreter-REPL is less reliable than a script?
> When you start a script, you have a consistent environment - an empty
> one. When you write a series of commands in the interactive
> interpreter, the environment for each one depends on all the preceding
> commands. So when you have a problem, you might have to copy and paste
> the entire interpreter session, rather than just the one command.

True, but the same applies to a script. If you have a problem with line 100,
you can't just post line 100, you may have to post the entire 100 lines
before it. Being able to isolate the problem to the minimal amount of code
needed to demonstrate it is an important skill for all developers.


More information about the Python-list mailing list