First, let me offer congratulations and heartfelt thanks for your hard work! Victor Stinner writes: > For network protocols, I don't know. It looks like the new email > modules will offer two API levels: low level (native type) using > bytes, high level using str (unicode). I don't know if the high > level API uses the PEP 383 or not. Give that about 0.3% of the mail in my system uses the UNKNOWN encoding in MIME-words, "best effort" to decode headers will require it. (Half-decoded text is a nightmare, of course.) > I don't use strict rules. Each problem is different. I agree. The reason is that the application must be designed to handle PEP 383 strings. If it isn't, you're just postponing the exception (perhaps to an unsuspecting second application). PEP 383 strings are an excellent, consistent way to handle broken text if your application is like email, where the design specifies passing around uninterpreted data, but transforming the representation is desirable. But many applications *should* just raise an exception here.
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