Title: Inconsistent 'file' vs 'stream' kwarg in pprint, other stdlibs
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.2
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: eric.araujo, pjenvey, r.david.murray
Priority: normal Keywords:

Created on 2009-06-06 22:02 by pjenvey, last changed 2010-11-12 02:29 by eric.araujo. This issue is now closed.

Messages (4)
msg89020 - (view) Author: Philip Jenvey (pjenvey) * (Python committer) Date: 2009-06-06 22:02
It'd be nice to eventually standardize on the kwarg name used for basic 
file-like args in the stdlib. print, warnings.showwarning and some 
others take a file= argument whereas pprint, getpass.getpass take 

print and pprint in particular should match -- though they do have a 
different option set, when you're using the same options this 
consistency would ease replacing:

print(obj, file=sys.stderr)
pprint(obj, stream=sys.stderr)
msg112300 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2010-08-01 09:39
@Philip can you provide a patch so we can take this forward?
msg121002 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-11-12 01:11
I’m afraid backward compatibility binds us here.  For new code however, it would be nice to use one name consistently.  My preference goes to “file”, because I really like the print function, but I suspect this could turn into bikeshedding quickly :)  I think this is too little an issue to warrant a line in the style guide.  Maybe just watch python-checkins and comment when someone adds a function using “stream”, “fp” or “fileobj”.  I suggest closing this report as wontfix.

You may want to open a new report about the matter of pprint and print having incompatible signatures.  How about proposing a new function, say pprint.print, which could be a drop-in replacement for builtins.print?
msg121009 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-11-12 01:57
Yes, simply saying "make it consistent" is a won't fix, because of backward compatibility issues.  Specific proposals for specific functions in a way that deals with the backward compatibility issues should be opened as new issues.
Date User Action Args
2010-11-12 02:29:23eric.araujosetstatus: open -> closed
2010-11-12 01:57:38r.david.murraysetnosy: + r.david.murray
messages: + msg121009

resolution: wont fix
stage: needs patch -> resolved
2010-11-12 01:11:10eric.araujosetnosy: - BreamoreBoy
messages: + msg121002
2010-08-01 09:39:41BreamoreBoysetversions: + Python 3.2
nosy: + BreamoreBoy

messages: + msg112300

stage: needs patch
2009-06-27 15:04:16eric.araujosetnosy: + eric.araujo
2009-06-06 22:02:07pjenveycreate