PEP 259: Omit printing newline after newline 
Author Message
 PEP 259: Omit printing newline after newline

I have to say, I'm strongly against this PEP... does anyone else agree with
me?
Quote:
----- Original Message -----

Subject: Re: [Python-Dev] PEP 259: Omit printing newline after newline


> > Please comment on the following.  This came up a while ago in
> > python-dev and I decided to follow through.  I'm making this a PEP
> > because of the risk of breaking code (which everybody on Python-dev
> > seemed to think was acceptable).

> > --Guido van Rossum (home page: http://www.*-*-*.com/ ~guido/)

> > PEP: 259
> > Title: Omit printing newline after newline
> > ...
> > Scope

> >     This only affects printing of 8-bit strings.  It doesn't affect
> >     Unicode, although that could be considered a bug in the Unicode
> >     implementation.  It doesn't affect other objects whose string
> >     representation happens to end in a newline character.

> I guess I should fix the Unicode stuff ;-)

> > Risks

> >     This change breaks some existing code.  For example:

> >         print "Subject: PEP 259\n"
> >         print message_body

> >     In current Python, this produces a blank line separating the
> >     subject from the message body; with the proposed change, the body
> >     begins immediately below the subject.  This is not very robust
> >     code anyway; it is better written as

> >         print "Subject: PEP 259"
> >         print
> >         print message_body

> >     In the test suite, only test_StringIO (which explicitly tests for
> >     this feature) breaks.

> Hmm, I think the above is a very typical idiom for RFC822
> style content and used in CGI scripts a lot. I'm not sure whether
> this change is worth getting the CGI crowd upset...

> Wouldn't it make sense to only use this technique in inter-
> active mode ?

> --
> Marc-Andre Lemburg
> CEO eGenix.com Software GmbH
> ______________________________________________________________________
> Company & Consulting:                           http://www.*-*-*.com/
> python Software:                         http://www.*-*-*.com/

> --
> http://www.*-*-*.com/



Sat, 29 Nov 2003 10:13:34 GMT  
 PEP 259: Omit printing newline after newline

I'm for it.  In fact, we should do things like this more often -- if the
semantics of "print" change once per release, everyone will stop using it,
the keyword/bytecode will vanish, and people will use a function for
writing to standard out, as it should have been all along! :)

Quote:

> I have to say, I'm strongly against this PEP... does anyone else agree with
> me?

                      ______      __   __  _____  _     _
                     |  ____ |      \_/   |_____] |_____|
                     |_____| |_____  |    |       |     |

                     http://twistedmatrix.com/users/glyph


Sat, 29 Nov 2003 10:22:54 GMT  
 PEP 259: Omit printing newline after newline

Quote:

> > Please comment on the following.   ...

> > PEP: 259
> > Title: Omit printing newline after newline
[ ... ]

> Wouldn't it make sense to only use this technique in inter-
> active mode ?

Blerch! I'm agin differences between the behavior of the interpreter
interactively and non-interactively. Reminds me of various Unixoid filters
whose code is full of "am I reading from a pipe" questions. Also, since
interactive mode is so useful for development of code which then gets
grafted into programs it would be confusing to have different behaviors in
two modes. Or am I missing the point?

regards
 Steve



Sat, 29 Nov 2003 11:56:59 GMT  
 PEP 259: Omit printing newline after newline

Quote:

>I'm for it.  In fact, we should do things like this more often -- if the
>semantics of "print" change once per release, everyone will stop using it,
>the keyword/bytecode will vanish, and people will use a function for
>writing to standard out, as it should have been all along! :)

Why do you insist on using function instead of print statement?
Maybe, we can also eliminate del statement because there is no
"new" cunterpart of it?

print is nice as it is. Please, leave it along.

Quote:

>> I have to say, I'm strongly against this PEP... does anyone else agree with
>> me?

>                      ______      __   __  _____  _     _
>                     |  ____ |      \_/   |_____] |_____|
>                     |_____| |_____  |    |       |     |

>                     http://twistedmatrix.com/users/glyph

Sincerely yours, Roman Suzi
--

_/ Tuesday, June 12, 2001 _/ Powered by Linux RedHat 6.2 _/
_/ "My cat likes to play Hide-And-Go-Poop." _/


Sat, 29 Nov 2003 14:00:15 GMT  
 PEP 259: Omit printing newline after newline

Quote:

> >I'm for it.  In fact, we should do things like this more often -- if the
> >semantics of "print" change once per release, everyone will stop using
it,
> >the keyword/bytecode will vanish, and people will use a function for
> >writing to standard out, as it should have been all along! :)

> Why do you insist on using function instead of print statement?
> Maybe, we can also eliminate del statement because there is no
> "new" cunterpart of it?

Axiom: a function does not affect its caller's namespace --
it does not bind, it does not unbind, it does not re-bind.

Lemma: any construct that, by design, must affect the "caller's"
namespace should not be a function, but rather a statement.

ObBadExample: execfile.  It's a statement in function's
clothing.  And thus, it works quite badly:

D:\py21>python
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
Alternative ReadLine 1.4 -- Copyright 2001, Chris Gonnerman

Quote:
>>> print open('fo.py').read()

a=23

Quote:
>>> execfile('fo.py')
>>> a
23
>>> del a
>>> def f():

...     execfile('fo.py')
...     print a
...
Quote:
>>> f()

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 3, in f
NameError: global name 'a' is not defined
Quote:

>>> def g():

...     a=5
...     execfile('fo.py')
...     print a
...

Quote:
>>> g()
5

Clearly we do NOT want other such semi-working hacks -- one
is more than enough:-).

Therefore: assignment and del, whose PRIMARY purpose is
affecting the namespace in which they're used, MUST be
statements.  class, def, import, from, for, affect the
namespace in which they're used as part of their
operation -- this is maybe a secondary effect that is
not always wanted in the case of 'for', but it's very
much a part of normal operation for the others.  OK so
far...?  Oh, exec, too -- to ALLOW it to affect the
namespace in which it's used, specifically!

Another reason to make something a statement is when
the 'something' contains one or more blocks of code
and/or affects control flow. class, def and for meet
this test too.  while, if, try, raise, break, return,
continue -- all affect control flow.  pass can also
be seen this way -- it has NULL effect on control flow
(or anything else), making it a suitable place-holder
and allowing Python to avoid the syntax problems that
come with a "null statement" like in C & descendants.

So, summarizing: in Python, keyword statements either
affect the namespace using them, or affect the control
flow that uses them.

All, that is... except ONE.

That one is: print.  A keyword statement that neither
affects the namespace, nor control flow.  An anomaly,
therefore, that sticks out like a sore thumb.  Surely
not such a huge one that it's worth breaking 99% of
existing scripts to remove it:-).  *However* -- why
keep overloading it with magic and extra "convenience"
features...?  Glyph may be right in paradoxically
claiming that just such tweaking will eventually show
everyone that print is just best not used:-).

To HELP migration to a function for what is now done
with print, I think such a built-in function should be
added contextually to this latest 'print' change.  Yes,
yes, it IS un-Pythonic to provide several ways to do
the same task, but, here, I think, we need to patch
over the non-Pythonic existence of print itself:-).

I believe the new print-like built-in function should
ideally be named print, but we can't do it, because
keywords are reserved.  Sigh.  Among the alternatives,
we have: write (misleading as it recalls the write
method of file-objects), output (makes for a nice
pair with input, which, however, has its own {*filter*}
problems:-), emit, say (a la Rexx), echo (a la sh),
and many others, including non-words that decorate
these basic words (doprint, etc).

Whatever name is used (assume 'output' for definiteness,
without loss of generality), I think the print-like
function should accept arbitrary unnamed arguments
(to be treated just like the items now passed to
print) optionally followed by named arguments to
supply the same tweaks that now print supplies (and
maybe a few more) -- names are doubtful, but...:
    file=sys.stdout   the output file-object to use
    newl=1            1 emit a newline at the end
                        UNLESS the last item printed
                        is a string ending in \n
                        (like print will now work)
                      0 no newline at the end (like
                        print with a trailing comma)
                      2 force newline at the end in
                        any case (like print today)
    (others?)

a la (2.2 syntax, untested):

def output(*args, **kwds):
    file = sys.stdout
    newl = 1
    for k in kwds:
        if k=='file': file=kwds[k]
        elif k=='newl': newl=kwds[k]
        else:
            raise TypeError, \
                "output() got an unexpected keyword argument '%s'"%k
    # I'm just approximating softspace behavior here...:
    soft = getattr(file, 'softspace', 0)
    no_end_nl = 1
    for a in args:
        if soft: file.write(' ')
        towrite = str(a)
        no_end_nl = towrite=='' or towrite[-1]!='\n'
        file.write(towrite)
        soft = file.softspace = no_end_nl
    if newl:
        file.softspace = 0
        if newl==2 or no_end_nl:
            file.write('\n')

Having output as a built-in function would encourage
using it in lieu of the print statement, which, in
turn, would allow the usual kind of tricks that are
available for built-ins but not for statements, such
as wrapping/overriding (you can do that for print with
a user-defined file-like object, to some extent, but
not fully -- the file-like object cannot know where
a given print statement begins or ends, it can only
intercept specific write and softspace accesses).

Alex



Sat, 29 Nov 2003 17:29:50 GMT  
 PEP 259: Omit printing newline after newline
Chris Gonnerman wrote in comp.lang.python:

Quote:
> I have to say, I'm strongly against this PEP... does anyone else agree with
> me?

I agree. It's special casing, and it breaks much of the code out there that
prints header style things (CGI, mail, other http things...), and I don't
see a lot of benefit.

--
Remco Gerlich



Sat, 29 Nov 2003 18:23:01 GMT  
 PEP 259: Omit printing newline after newline

Quote:
> No, no! Do not take print away! It help to migrate from Basic! ;-)

This is the best single reason I can see OTHER than not breaking existing
scripts.
Not just BASIC, but Perl, and SO MANY other languages have a print
statement.

IMHO Alex's output() function is not really necessary.  If you hate print,
use
fileobj.write(), and leave us print-users alone.

Aesthetics alone are not a good enough reason for such a fundamental and
painful
change.



Sat, 29 Nov 2003 19:58:21 GMT  
 PEP 259: Omit printing newline after newline

Quote:




>Another reason to make something a statement is when
>the 'something' contains one or more blocks of code
>and/or affects control flow. class, def and for meet
>this test too.  while, if, try, raise, break, return,
>continue -- all affect control flow.  pass can also
>be seen this way -- it has NULL effect on control flow
>(or anything else), making it a suitable place-holder
>and allowing Python to avoid the syntax problems that
>come with a "null statement" like in C & descendants.

>So, summarizing: in Python, keyword statements either
>affect the namespace using them, or affect the control
>flow that uses them.

>All, that is... except ONE.

>That one is: print.  A keyword statement that neither

May be allow to call functions as statements then?
Then there will be no difference:

print 1, 2, 3

or

print(1, 2, 3)

Or:

write file, "this is line"

Oh... It will be Tcl then...

No, no! Do not take print away! It help to migrate from Basic! ;-)

Sincerely yours, Roman Suzi
--

_/ Tuesday, June 12, 2001 _/ Powered by Linux RedHat 6.2 _/
_/ "My cat likes to play Hide-And-Go-Poop." _/



Sat, 29 Nov 2003 19:03:44 GMT  
 PEP 259: Omit printing newline after newline

Quote:

> I have to say, I'm strongly against this PEP... does anyone else agree with
> me?

        I have never before felt compelled to comment on a PEP.  I
even run into the example case (filtering Unixy config and account
maintenance files), bu I have to say "nay" to this one.  Loudly.

        Less magic!

--
William Annis - System Administrator - Biomedical Computing Group

Mi parolas Esperanton - La Internacian Lingvon  www.esperanto.org



Sat, 29 Nov 2003 20:48:23 GMT  
 PEP 259: Omit printing newline after newline

    ...

Quote:
> >That one is: print.  A keyword statement that neither

> May be allow to call functions as statements then?
> Then there will be no difference:

There are languages that wipe out any difference between
statements and expressions (including function calls).

Python is definitely *NOT* one of those.  Expressions
can be used as statements (which occasionally causes a
few problems, too:-), but not vice versa.  It's highly
unlikely that Python will ever change so deeply as to
heal THIS 'split' -- particularly since it is not
generally perceived as a problem:-).

Quote:
> write file, "this is line"

> Oh... It will be Tcl then...

Visual Basic 6 used to have this idea (that you could
do without the parentheses in a subroutine call), but
VB is losing it in the move to VB .NET (one of many
incompatible changes to VB in the 6->.NET migration --
ALL of the changes take VB slightly closer to Python,
in syntax and/or semantics, as I mentioned in a post
a few days ago).

Would you really like to have to invent a new set
of rules to distinguish whether
    pow(2,3),4
(a 2-element tuple (8,4)) or
    pow(2,3,4)
(integer 0) is meant when one writes
    pow 2, 3, 4
...?-)  Perl has enough trouble with that one, I
think.  Simple, regular use of parentheses for any
function call is one of the many aspects that make
Python syntax simpler and more effective.

Alex



Sat, 29 Nov 2003 20:40:04 GMT  
 PEP 259: Omit printing newline after newline
I'm against this for the following reasons:
1) will break a lot of existing CGI code
2) will break a lot of rfc822 code
3) will break just about every file-massaging program I've written
(I'm a sysadmin, I massage a lot of files)
4) the behaviour of the print statement will become non-deterministic

I really like Alex's output() (or whatever you want to call it)
function and would use it in a heartbeat.  I would also be much more
interested in being able to supply a keyword argument to readlines()
that would have it strip the EOL character(s).

Just my $0.02.



Sat, 29 Nov 2003 21:20:12 GMT  
 PEP 259: Omit printing newline after newline

Quote:

> > No, no! Do not take print away! It help to migrate from Basic! ;-)

> This is the best single reason I can see OTHER than not breaking existing
> scripts.
> Not just BASIC, but Perl, and SO MANY other languages have a print
> statement.

Ah, yes.  Perl compatibility is definitely a must, isn't it...?

Not VB, because that has no "print statement" -- is has a
"print #" statement, and the #filenumber part is mandatory;
it writes to a disk file.

Not C, which uses a printf *FUNCTION*.  Not C++ (which uses
the << operator).  Not Java.  If compatibility or migration
help from other languages is "the best reason" (apart from
not breaking working code) for print's existence as a
statement, then it seems the reasons in print's favour
are even weaker than I thought.

Meanwhile, there ARE people out there (beginners, but not
idiots:-) who might like
    print
to PRINT -- yet when they use it, their printer doesn't do
anything... stuff gets displayed on-screen, NOT printed.

Those guys and gals have never seen a 'printing terminal',
and this idiomatic usage of a verb which DOES have an
obvious, different, and perfectly current meaning in
'computerese' is hardly a good idea in a CP4E setting.

Quote:
> IMHO Alex's output() function is not really necessary.  If you hate print,
> use fileobj.write(), and leave us print-users alone.

Several built-in functions "are not really necessary".
Why have dir(x) when vars(x).keys() is equivalent, for
example?  Speed, convenience, solidity.

If an output function were defined, it could play the
same role wrt the print statement as __import__ plays
wrt the import and from statements.  The statement
would remain (of course: breaking a vast majority of
all scripts would be silly), *AND* it would be
defined and documented to internally invoke the function.

So the programmer gets a chance to "override" the
function and get a global effect even when another
module used the statement instead.  Perhaps, in this
spirit, the function should be named __print__, then.

Quote:
> Aesthetics alone are not a good enough reason for such a fundamental and
> painful change.

Absolute agreement here!  Aesthetics are shifty, and a
frail reed indeed.  Hardly good reason for ANY change
(for doing things right in the first place, maybe, but
not even Guido can get 100% right -- yet he has a far
better track record in taking right design decisions
than anybody else I've ever met or heard about:-).

But the statement/function distinction is NOT chiefly
about "aesthetics".  It IS chiefly about functionality.

print has no real reason to exist as a statement, but,
OK, it get grandfathered in (note that this would argue
for leaving the default to respect-all-newlines, rather
than Guido's new idea of removing SOME newlines).  Having
print as a statement gives no real advantage, but it does
give some disadvantages _unless_ the underlying functionality
can be tweaked.  You can do MANY tweaks by using a wrapped
file-like-object as stdout, but NOT all -- the file-object
is not "told" about how many print statements are being
processed, so it can't do such tweaks as the one that is
now being proposed by Guido.  A __print__ underlying
function would solve that.  Having a friendly name such
as output is nice but secondary.

So why don't I write my output() function and just use
it?  That's not enough, because I use a lot of code I
did not write -- and that code "coming from outside" is
not going to use MY private conventions.  If it uses
(overtly or indirectly) a built-in function, I get a
chance to wrap that and make the code-from-outside of
some use for my purposes.  Otherwise, I'm SOL.

See why one should use isinstance(x,y) even when y is
a type-object, for example?  Why not just type(x)==y?
*Because* the latter idiom is not sensibly tweakable
non-invasively -- I can hardly wrap/override type()
without knowing what's going to be done with its
result.  I _can_ at least wrap isinstance, and thus
defeat some of the typechecks that may be killing me
in external code I'm reusing...:-).  [Maybe not the
best of examples, because it's STILL a bother, but,
until and unless we get PEP 246, it's gonna be hard
to uproot typechecks altogether:-)].

Alex



Sat, 29 Nov 2003 21:08:23 GMT  
 PEP 259: Omit printing newline after newline


<snip>

Quote:
> Those guys and gals have never seen a 'printing terminal',

Totally off topic:

But this reminds me of remotely debugging an HP 2000 Basic app designed to
run on a  Hazeltine 1500 block mode terminal.  We followed the code while
the user talked us through his steps.  No way was this happening.  We asked
him to go slower, and tell _everything_ he did.  Only when he got to "...
then I scroll the paper back..." did we figure out he was on a TI810 hard
copy terminal.  ;-)

--

Emile van Sebille

---------



Sat, 29 Nov 2003 22:00:35 GMT  
 PEP 259: Omit printing newline after newline


    ...

Quote:
> I really like Alex's output() (or whatever you want to call it)
> function and would use it in a heartbeat.  I would also be much more
> interested in being able to supply a keyword argument to readlines()
> that would have it strip the EOL character(s).

An interesting idea would be (yeah, yeah, I know -- my name
is Alex, and I am an overgeneralizer) to have a named parameter
ln uniformly accepted by all functions and methods dealing
with lines.  Default would be ln=1 for functions & methods
that now respect/don't add newlines (readline, readlines,
write, writelines, xreadlines, ...), ln=0 for those that
now generally add/remove newlines (print -- or rather its
function-equivalent -- say 'output', raw_input).  Being
"everywhere" would make it easy indeed to teach to newbies.

Being a keyword argument would make life easy for advanced
users, as suggested in my last post, i.e. rather than
    if somecondition():
        print blah, bloh,
    else:
        print blah, bloh
or
    print blah, bloh,
    if somecondition():
        print
just
    output(blah, bloh, ln=
        somecondition())
...

Akex



Sat, 29 Nov 2003 22:06:08 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. PEP 259: Omit printing newline after newline

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

3. Newline Suppression in Print

4. instead of single column, print fields 3 or 4 across then newline

5. Printing newlines

6. echo, print and the newline character

7. Q: print and newline

8. print without newline?

9. print without newline

10. Printing without newlines..

11. Print characters on one line without newline...???

12. How to get newline to do newline-and-indent in scheme interaction?

 

 
Powered by phpBB® Forum Software