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

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

On Jan 21, 2004, at 12:50 PM, Marc-Antoine Parent wrote:

>> The simple fact of the matter is that NSString is the equivalent to 
>> python's unicode.  If you unicode('something-with-latin-1') then you 
>> will get an exception.  There is no reason whatsoever to put 
>> arbitrary data in a NSString unless you know its encoding.
>
> 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.  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.

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

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

-bob