[Python-Dev] a suggestion ... Re: PEP 383 (again) (original) (raw)
"Martin v. Löwis" martin at v.loewis.de
Thu Apr 30 07:24:34 CEST 2009
- Previous message: [Python-Dev] a suggestion ... Re: PEP 383 (again)
- Next message: [Python-Dev] a suggestion ... Re: PEP 383 (again)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Curt Hagenlocher wrote:
On Wed, Apr 29, 2009 at 8:16 PM, Thomas Breuel <tmbdev at gmail.com> wrote:
Also, what are Jython and IronPython supposed to do on UNIX? Can they implement these semantics at all? IronPython will inherit whatever behavior Mono has implemented. The Microsoft CLR defines the native string type as UTF-16 and all of the managed APIs for things like file names and environmental variables operate on UTF-16 strings -- there simply are no byte string APIs. I assume that Mono does the same but I don't have any Mono experience.
Marcin Kowalczyk once did a review, at
http://mail.python.org/pipermail/python-3000/2007-September/010450.html
It may have changed since then; at the time, Mono would omit non-decodable files in directory listings, and would refuse to start if a non-decodable command line argument is passed. The environment variable MONO_EXTERNAL_ENCODINGS can be set to specify what encodings should be tried in what order.
However, I don't think it is relevant for the PEP: as Curt says, these details will be inherited from the VM; the mechanism proposed is really specific to CPython. To implement it on the other VMs, those would have to either implement it natively, or provide byte-oriented APIs to allow Jython/IronPython to implement it on top of it (the latter being not realistic or useful).
Regards, Martin
- Previous message: [Python-Dev] a suggestion ... Re: PEP 383 (again)
- Next message: [Python-Dev] a suggestion ... Re: PEP 383 (again)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]