Python is going to be hard

[Chris Angelico]

On Thu, Sep 4, 2014 at 11:25 PM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> 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:
>
> 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.

Focusing everything on output, yes that's a problem. (Look at the ob_*
functions in PHP - they are an abomination built to cope with other
abominations.)

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

I agree that it's limited - but how would you do it differently?
Python's repr for multiline text is pretty unreadable. The only way I
could imagine it being done is if it returns a custom object whose
repr is the text we usually see. If you want to send it somewhere
other than the console. dis.dis(file=...) works; and if you want to do
something other than simple output, you probably want one of the
lower-level functions (which I haven't personally dug into, but I'm
thinking get_instructions is probably more useful than dis for more
complicated jobs).

>> 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.

Sure, but if you hate something enough to scream "NO PRINT" at us,
isn't it a bit odd to advocate something that does the exact same
thing only hidden? Why is it somehow okay to rely on the side effect
of intermediate expression results getting printed, while decrying
side effects anywhere else?

>>> 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.

Yes, that's true. But a dozen-line script that's been through a dozen
iterations of editing is still a dozen lines of script, whereas it
might be sixty or seventy lines of interactive output. It's generally
easier to "isolate to the minimum" when you start with something
that's inherently shorter. It's also easier to isolate to the minimum
when you work with a consistent starting position, rather than have
each one build on the preceding ones.

Like I said in my most recent response to Rustom, we probably don't
disagree nearly as much as it seemed at the first couple of responses.

ChrisA