On Thu, Jul 7, 2011 at 6:49 PM, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote: > Nick Coghlan <ncoghlan <at> gmail.com> writes: > >> Unless somebody steps forward to fix them, the Stream* classes have to >> go (albeit with a suitable period of deprecation). They're *actively >> harmful* in their current state, so retaining the status quo is not a >> viable option in this case. > > I can understand that there might be specific issues with them, but isn't > "actively harmful" a little strong? I don't see who is being actively harmed by > them, nor how. 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. Codec writers are also told to implement utterly unnecessary functionality just because PEP 100 says so. Significantly less common, but still harmful. 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) Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4