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.
>> 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.
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.
> 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
> 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?
The bootstrap script sets your PYTHONPATH to the Resources folder, so=20
you can put a sitecustomize.py there and it will just work