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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
