[Patches] [Patch #100970] extended print statement

noreply@sourceforge.net noreply@sourceforge.net
Sat, 19 Aug 2000 18:46:19 -0700


Patch #100970 has been updated. 

Project: 
Category: core (C code)
Status: Accepted
Summary: extended print statement

Follow-Ups:

Date: 2000-Jul-23 22:44
By: bwarsaw

Comment:
This patch provides one approach to an extended print statement which allows you to specify the file-like object to print to (instead of the default sys.stdout).  This adds two new opcodes and works by temporarily binding sys.stdout during the execution of the print statement.

An alternative approach would be to include one new opcode, called PRINT_ITEM_TO which would put the file-like object on top of the stack for each call to PRINT_ITEM.  I'm not sure which approach is better.
-------------------------------------------------------

Date: 2000-Jul-23 22:45
By: bwarsaw

Comment:
The following is an example of how you might use the new extended print statement.

<pre>
import sys
from StringIO import StringIO

listname = 'mylist'
sender = 'barry@beopen.com'
msg = 'x' * 1000

print 'post to', listname, 'from', sender, 'size=', len(msg)
print >> sys.stdout, 'post to', listname, 'from', sender, 'size=', len(msg)

log = StringIO()
print >> log, 'post to', listname, 'from', sender, 'size=', len(msg)
print log.getvalue(),
</pre>

-------------------------------------------------------

Date: 2000-Aug-15 14:00
By: tim_one

Comment:
Assigned to Guido for Pronouncement.  This was already discussed on Python-Dev.  Mix of opinions there.  I like it fine.

Barry, this needs docs and test cases Real Soon if you want it considered for 2.0.  I like the PRINT_TO idea better.
-------------------------------------------------------

Date: 2000-Aug-15 18:43
By: bwarsaw

Comment:
Revised patch which uses the PRINT_ITEM_TO approach favored by Tim.  This patch also includes doc and test suite updates.  Please see PEP 214 for a discussion of the issues.  This feature should be postponed until Python 2.1
-------------------------------------------------------

Date: 2000-Aug-15 19:05
By: tim_one

Comment:
I don't understand.  If you wanted to Postpone it, you could have done so yourself.  Why do you want to postpone it?  It's already been discussed, and the patch was submitted well before the feature-freeze date.
-------------------------------------------------------

Date: 2000-Aug-15 19:16
By: bwarsaw

Comment:
Okay, I just thought that with the open issue (see PEP 214) it might not be ready for prime time.  Let's wait for the BDFL pronounce before postponing.
-------------------------------------------------------

Date: 2000-Aug-15 19:33
By: tim_one

Comment:
I don't understand.  If you wanted to Postpone it, you could have done so yourself.  Why do you want to postpone it?  It's already been discussed, and the patch was submitted well before the feature-freeze date.
-------------------------------------------------------

Date: 2000-Aug-16 10:56
By: bwarsaw

Comment:
After channeling and encouragement from Tim, this patch represents the current definition of the feature as described in PEP 214.  It is now ready for BDFL pronouncement for Python 2.0.
-------------------------------------------------------

Date: 2000-Aug-17 15:31
By: gvanrossum

Comment:
I'm still not convinced.  Let's save this for reopening in 2.1.   I'm worried about language bloat...  Assigned to Tim just so that he can reopen the debate when he sees fit.
-------------------------------------------------------

Date: 2000-Aug-19 21:46
By: tim_one

Comment:
Changed status from Postponed to Accepted and assigned back to Barry for checkin.

Ruling from Guido follows:

I'm still reading my email off-line on the plane. I've now read PEP 214 and think I'll reverse my opinion: it's okay. Barry, check it in! (And change the SF PM status to 'Accepted'.) I think I'll start using it for error
messages: errors should go to stderr, but it's often inconvenient, so in minor scripts instead of doing

  sys.stderr.write("Error: can't open %s\n" % filename)

I often write

  print "Error: can't open", filename

which is incorrect but more convenient. I can now start using

  print >>sys.stderr, "Error: can't open", filename

--Guido

-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100970&group_id=5470