[Python-Dev] Draft PEP: Deprecate codecs.StreamReader and codecs.StreamWriter
Vinay Sajip
vinay_sajip at yahoo.co.uk
Thu Jul 7 12:53:56 CEST 2011
Nick Coghlan <ncoghlan <at> gmail.com> writes:
> Anyone forward porting codecs.open based code will get subpar IO in
> Python 3 *because* they're trying to do the right thing in Python 2.
> That's actively harmful in my book.
I see. Presumably if they're doing a porting exercise, then it's easy enough for
them to convert codecs.open() calls to open(), if they don't want the
performance to be sub-optimal. But I thought the main thrust of this was about
deprecation of the Stream* classes, not open() vs. codecs.open().
> Codec writers are also told to implement utterly unnecessary
> functionality just because PEP 100 says so. Significantly less common,
> but still harmful.
Presumably only an issue for anyone writing new codecs for 2.x - I'm not sure
how many cases that'd be.
> The bare minimum change needed is for codecs.open() to do the right
> thing in Py3k and be a wrapper around builtin open() and the main IO
> stack. Once that happens, the legacy Stream* APIs become redundant
> cruft that should be deprecated (although that part is significantly
> less important than fixing codecs.open() itself)
I've no issue with telling people to use open() rather than codecs.open() when
moving code from 2.x to 3.x. But in 2.x, is there any other API which allows you
to wrap arbitrary streams? If not, then ISTM that removing the Stream* classes
would give 2.x->3.x porting projects more trouble than codecs.open() -> open().
Regards,
Vinay Sajip
More information about the Python-Dev
mailing list