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

[Bob I. <bo...@re...>]

On Jan 21, 2004, at 3:17 PM, Marc-Antoine Parent wrote:

>> I think I understand your problem now, you have a console program=20
>> that is interacting with a GUI application  via a pipe.  This GUI=20
>> application is trying to display the output of your program, but=20
>> since it does not know the encoding of your text it is passing on=20
>> NSString and crossing its fingers.
>
> That is indeed my case.
> I was trying to make a more general argument, about third-party=20
> non-unicode libraries in general, but I will admit it is theoretical.=20=

> I still feel that the fact that there is a single point of conversion=20=

> in the PyObjC bridge makes it a very practical point of control. But I=20=

> will now try to restrain myself to my current problem.

Encodings are serialization formats, beyond that you need to be using=20
unicode.  This is by far one of the worst things about Python: we have=20=

this AWESOME unicode support, but we forget to use it most of the time=20=

because it requires us to put a u in front of our text.  Hopefully=20
someday, Python str will be crippled to the point where nobody will=20
want to use it for anything but raw data.

>>  The correct solution is, of course, to fix the GUI application; the=20=

>> way it is handling text is broken.
>>
>> Solution:
>> Possibly use a configuration panel for the GUI to choose the encoding=20=

>> of incoming pipes
>> Use codecs.getreader(your_encoding) on the pipe, and use that to=20
>> create NSStrings....
>
> Yes, in this case, we can ask Glen about it (I have) and/or do the=20
> change (I may.)
> If the application were closed source, I would be in more trouble.=20
> Hence my request.

The truth of the matter is that the application is broken, whether it's=20=

open source or closed.

<offtopic>
Because it's open source, and you're a developer, you have this=20
wonderful i-can-fix-it-if-i-have-to power over your software.  That's=20
what I really like about open source.  I don't particularly care for=20
the rest of it (especially annoyances like the GPL and even LGPL).  If=20=

everyone just used Python/BSD/MIT-style licenses, then we could all=20
share code and not have to hire a lawyer to see if we can reuse=20
something in another open source project with a different license.
</offtopic>

> Le 04-01-21, =E0 14:57, Ronald Oussoren a =E9crit :
>
>>> The fact that setdefaultencoding can only be set at startup is a=20
>>> major limitation, and the reason that I argue for a separate value=20=

>>> in the bridge.
>>
>> And the fact that setdefaultencoding exists and is removed early=20
>> during startup is an important reason for not adding a simular=20
>> function to PyObjC.
>
> I am arguing it is not similar, as it controls a single point of=20
> conversion (communication with the Cocoa code) as opposed to Python=20
> behaviour as a whole.
> I assume it makes sense, in that (in my limited experience) the Cocoa=20=

> interface is mostly used to talk with the UI, which is a well-defined=20=

> subset of the API.
> Though I admit that this would also affect other parts of the Cocoa=20
> bridge, if used, which is as bad as changing Python as a whole.
>
>> If you really want to change the encoding after startup you should=20
>> probably file a bugreport for Python, or ask around on=20
>> comp.lang.python.
>
> Fair, but I still think that my case is slightly different.
>
>> BTW. If you build .app bundles you can completely replace the site.py=20=

>> inside your application
>
> Ah? How, out of curiosity?

http://pythonmac.org/wiki/BundleBuilder

The bootstrap script sets your PYTHONPATH to the Resources folder, so=20
you can put a sitecustomize.py there and it will just work

-bob