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

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

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

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

> I would almost vote to *disable* the str<->NSString bridge in PyObjC, 
> or make it bridge NSData instead, but that would just be terribly 
> inconvenient for many people.

Indeed.

Marc-Antoine Parent