[Python-Dev] My work on Python3 and non-ascii paths is done (original) (raw)
Stephen J. Turnbull stephen at xemacs.org
Sat Oct 23 06:01:14 CEST 2010
- Previous message: [Python-Dev] My work on Python3 and non-ascii paths is done
- Next message: [Python-Dev] Support for async read/write
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.
- Previous message: [Python-Dev] My work on Python3 and non-ascii paths is done
- Next message: [Python-Dev] Support for async read/write
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]