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

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

> I think I understand your problem now, you have a console program that=20=

> is interacting with a GUI application  via a pipe.  This GUI=20
> application is trying to display the output of your program, but since=20=

> it does not know the encoding of your text it is passing on NSString=20=

> 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. I=20=

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

the PyObjC bridge makes it a very practical point of control. But I=20
will now try to restrain myself to my current problem.

>  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.

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 in=20=

>> 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?

Marc-Antoine