Fwd: [Pyobjc-dev] depythonify_c_value rejects non-ascii, non-unicode strings

[Marc-Antoine P. <map...@ac...>]

I just referred to this message, and realized I had not Cc'd it to the=20=

list.

De: Marc-Antoine Parent <map...@ac...>
Date: 21 janvier 2004 12:56:57 GMT-05:00
=C0: Ronald Oussoren <ous...@ci...>
Objet: R=E9p : [Pyobjc-dev] depythonify_c_value rejects non-ascii,=20
non-unicode strings

> I don't like introducing global switches like this, libraries may=20
> modify the switch and change the behaviour of other code.

I agree with you in principle, but I would contend that the case where=20=

two distinct libraries would be using the PyObjC simultaneously should=20=

be comparatively rare. The user should only see one UI, no? (As opposed=20=

to non-UI libraries, which may be many.)
Of course, you may counter me with widget libraries; I would contend=20
that setting the encoding should only be done by the main application,=20=

for obvious reasons.
And a widget library that _needed_ to set that switch for whatever=20
reasons could save the current value in a local variable during its=20
operation, like any well-behaved piece of code.

>> Too bad that sitecustomize.py cannot in the same directory as a=20
>> script (dirname(sys.argv[0] is added after site.py finishes). BTW.=20
>> does anyone know why sys.setdefaultencoding is removed in site.py?=20
>> E.g. why is it good that users cannot change the default encoding=20
>> after the interpreter has initialized?
>
> sys.setdefaultencoding is probably removed in site.py for the same=20
> reason you don't like global switches.. someone could=20
> sys.setdefaultencoding in a module that you use, for example.

The fact that setdefaultencoding can only be set at startup is a major=20=

limitation, and the reason that I argue for a separate value in the=20
bridge.

Marc-Antoine Parent