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

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

>> That sentence agrees with my point the second time: What if I _do_ 
>> know the encoding, and I want to tell the bridge about it?
>> Your point is that I should convert strings to unicode before the 
>> bridge; my point is that I may be calling the bridge in quite a few 
>> places, and converting there may not be practical.
>> Whereas if the bridge had a simple API, viz.
>> PyObjC.setStringEncoding(str)
>> PyObjC.getStringEncoding()
>> getting and setting a variable which defaults to the system's default 
>> encoding,
>> then it would be easy to still use (single-byte) strings in Python if 
>> so desired (again, do realize that one is often dealing with someone 
>> else's code, and reengineering it is not always practical.)
>
> The problem with this proposal is that you want a function to change 
> the encoding related to *your* code, the proposed API changes the 
> encoding for *all* code that uses the bridge.

Do you mean that this global would be shared by two different python 
programs using the bridge? (i.e. in different processes...)
That would be indeed very dangerous and fully justify your reluctance. 
Otherwise, see my point in another post about uniqueness of GUI.

>  If you had control over all of the code then it would be fine, but in 
> that case you would also be able to just change Python's default 
> encoding.

Remember that I cannot do it after startup,

>>> If you want/need to exchange arbitrary data you're going to have to 
>>> explicitly put it in NSData.
>>
>> That would be valid for arbitrary data; but strings of a _known_ 
>> encoding are not arbitrary data.
>
> Yeah they are, they're arbitrary data until they're combined with the 
> encoding metadata -- which is the unicode type.

My point was to allow for more than one way to combine them. Unicode is 
one solution, and my favoured solution in most cases, but not always 
the best solution, and sometimes not practically available.

> In any case, this really just isn't going to happen.  There's too many 
> extremely good reasons not to do it.

Well, I will stop here, it is clear you do not find my arguments 
compelling, and that is unfortunately that.
We still disagree, but thank you for taking the time to give me your 
reasons.

Regards,

Marc-Antoine Parent