Guido van Rossum wrote: > OK, ignore my previous comment. Sounds like the inidividual codecs > need to tighten their type checking though -- perhaps *that* can be > fixed in 3.0.1? I really don't see why any codec used to convert > between text and bytes should support its output type as input. > > --Guido > > On Wed, Jan 7, 2009 at 10:26 AM, M.-A. Lemburg <mal at egenix.com> wrote: >> On 2009-01-07 16:34, Guido van Rossum wrote: >>> Sounds like yet another remnant of the old philosophy, which indeed >>> supported encode and decode operations on both string types. :-( >> No, that's something I explicitly readded to Python 3k, since the >> codecs interface is independent of the input and output types (the >> codecs decide which combinations to support). My memory is that making decode = bytes -> str and encode = str-> bytes was considered until it was noticed that there are sensible same-type transforms that fit the encode/decode model and then decided that reusing that model would be better than adding a transcode module/model. The bug of Unicode de/encoders allowing wrong inputs and giving weird outputs confuses people and has come up on c.l.p, so I think fixing it soon would be good. tjr
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