PEP 259: Revise to remove context-driven magic from print

[Michael Hudson]

robin900 at yahoo.com (Robin Thomas) writes:

> Feedback, please. If you all are positive about the proposal below,
> I'll work it up into a new PEP.

IMHO, starting afresh would be a better idea.

> Summary:
> 
> PEP 259 should be reworked to remove contextual magic from print
> statement, which was the main demand made by the Python community
> when *rejecting* the PEP. Then it could be resurrected from
> rejection.

I'm very much in the "ain't broke, don't fix it" category.

> Opinions:
> 
> 0) We don't need another built-in function that echoes what print
> does. Please.

Probably not.

> 1) We can't get rid of "print". It is a very common idiom in many
> languages.

Backwards compatibility?  Removing print would be *insane*, for
several reasons.

> 2) Python coders learn to avoid print because a print statement's
> behavior changes with a run-time context that the coder cannot
> necessarily control. To rehabilitate print, remove the context
> magic.

Not true, in my case.  I do use it mainly as a debugging tool, though.

> 3) Whenever I have a string of bytes that I wish to write to
> sys.stdout, without any formatting magic such as space characters or
> newlines, I cannot use the print statement, because it offers me no
> way to "turn off" all the formatting magic. Thus I am required to
> absorb the conceptual overhead of the sys module, sys.stdout and
> "standard output", file objects, and the write() method, just so that
> I can avoid having Python prepend a space character to my output in
> certain cases. For a novice Python coder, that sucks.

Oh please.  Novices can just use print.  Certainly, if you always
write

print a, b, c

rather than 

print a, b, c,

you're pretty unlikely to get into problems.  In fact the only way I
can conceive of problems arising is when you are writing code that
prints to stdout and interleaving that with calls to code that also
prints to stdout - and that's never going to work is it?

> 4) "softspace" has always seemed to me quite a lame thing to be part
> of the official file object API. What should file objects care about
> some cheesy report-printing operation like "print"?

I agree it's a hack, but thinks it's a reasonably clever one.

How else do you avoid

    >>> print "a",
    a>>> 

whilst also avoiding

    >>> print "a"
    a
    
    >>> 

?  I'm not convinced this is all worth the effort, mind.

> 5) The "am i at the start of a line context" only helps me when I want
> 
> print 1,2,
> print 3,4,
> print 5
> 
> to be equivalent to
> 
> print 1,2,3,4,5
> 
> ...and I have never exploited that feature of Python print, even in
> lazy report scripting, the application for which the feature seems to
> be intended.

I have.

[...]
> Proposed "new" PEP 259
> ---------------------------------
[...]
> 5) It is suggested that the values for "space separator" and "newline"
> be system-dependent, settable at run-time, and available in modules
> sys or os. Your feedback is welcome on this issue.

Hah!  You make an argument for removing complexity from print, and
then propose adding more!

If you want to print

"0-1-2-3+4-5-6+2"

you can do it yourself.  Furrfu.

[...]
> Again, print is not important enough to demand attention from
> designers of file-like objects.

You do realize that the softspace magic "just works" with most user
implemented files?  (ie. ones implemented in Python).

[...]

Run out of energy, sorry.

Cheers,
M.

-- 
    FORD:  Just pust the fish in your ear, come on, it's only a
           little one.
  ARTHUR:  Uuuuuuuuggh!
                    -- The Hitch-Hikers Guide to the Galaxy, Episode 1