This issue tracker has been migrated to GitHub ,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2009年06月06日 22:02 by pjenvey, last changed 2022年04月11日 14:56 by admin. 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 stream= 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) with 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. |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022年04月11日 14:56:49 | admin | set | github: 50475 |
| 2010年11月12日 02:29:23 | eric.araujo | set | status: open -> closed |
| 2010年11月12日 01:57:38 | r.david.murray | set | nosy:
+ r.david.murray messages: + msg121009 resolution: wont fix stage: needs patch -> resolved |
| 2010年11月12日 01:11:10 | eric.araujo | set | nosy:
- BreamoreBoy messages: + msg121002 |
| 2010年08月01日 09:39:41 | BreamoreBoy | set | versions:
+ Python 3.2 nosy: + BreamoreBoy messages: + msg112300 stage: needs patch |
| 2009年06月27日 15:04:16 | eric.araujo | set | nosy:
+ eric.araujo |
| 2009年06月06日 22:02:07 | pjenvey | create | |