Re: [Pyobjc-dev] Objective-C experts?

[Ken T. <ke...@co...>]

I can't claim to follow all of the details of how PyObjC works, but here are my impressions:

On Jun 12, 2012, at 10:13 AM, Ronald Oussoren wrote:

> trim_chars = u"*"
> #trim_chars = Cocoa.CFStringCreateWithCString(None, trim_chars, Cocoa.kCFStringEncodingASCII)
> 
> Cocoa.CFStringTrim(s, trim_chars)

Here, there are two paths, depending on whether that line above is commented out.  Either a unicode object is implicitly converted to a CFString/NSString or a it's an objc.pyobjc_unicode object wrapping what's already a CFString/NSString.  What are the code paths used by the two cases?  A lot of it is implicit and I'm not able to follow it.

> For me te problem only occurs when I run this code with a 64-bit build of python ("arch -x86_64 python2.7 ...") and works fine in a 32-bit build ("arch -i386 python2.7 ..."). I have only tested on OSX 10.7, I'm currently traveling and cannot easily test on other releases.  To make life even more interesting, the problem only occurs when "PyObjC_UNICODE_FAST_PATH" is active.

I note that PyObjC_UNICODE_FAST_PATH affects PyObjCUnicode_New() as well as the implementation of OC_PythonUnicode.  I recommend that, instead of disabling it globally by tweaking the header, you disable it in each translation unit independently to isolate which is the problem.  I'm sort of suspecting it's PyObjCUnicode_New() rather than OC_PythonUnicode, especially given that you tried disabling the implementation of -getCharacters:range:.

I also note that PyObjCUnicode_New() uses the deprecated method -getCharacters: (no range) when the Unicode fast path is enabled.  Other than that, I see no obvious problems with either code.

Given the 32-/64-bit difference, I was for a while suspecting that Py_UNICODE might be 4-byte UCS32 under 64-bit, but I see that PyObjC_UNICODE_FAST_PATH would not be enabled in that case. *shrug*

Regards,
Ken