Re: [Pyobjc-dev] Bridging strings from Python to other languages

[Bill B. <bb...@co...>]

On Wednesday, Feb 5, 2003, at 13:52 US/Eastern, Just van Rossum wrote:
> [keeping python-dev out of this]
> Bill Bumgarner wrote:
>> (3) identity is maintained;   pass a string with id() 7570720 from
>> Python into the alien runtime and subsequently from the alien runtime
>> back into python and the same string instance with id() 7570720
>> really should come back
> I was going to say (but Guido beat me to it ;-): from a *Python*
> perspective this is an absolutely silly requirement. But it's also the
> exact opposite of what you said earlier: that identity sometimes 
> matters
> in *ObjC*. You mentioned NSMapTable, but didn't answer my question how
> the semantics of NSMapTable are a) visible from Python and b) 
> _relevant_
> to Python coders.

You're right-- it is silly.   I should have flipped the example around: 
  Pass a string with (id) (0x1234) from ObjC into Python and back out 
again and the (id) should remain the same.   It may be a silly 
requirement for strings, but it is not a silly requirement for objects 
-- a string is just another object and there are those contexts, more 
common in spastically optimized C-derived compiled languages than in 
interpreted languages, where the class is irrelevant and the identity 
of the object is what matters.

The Python developer will never see NSMapTable, unless we bridge that 
particular API (not much point, but maybe some day).

But that doesn't mean an NSMapTable will not be in use in the 
underlying frameworks.   NSMapTable is [very likely -- it used to be, 
but they may have switched to other similar CF* APIs by now -- same 
problem] used within the AppKit implementation.

Any of the various APIs that provide map like access to internal state 
may very likely use an NSMapTable.   If they don't know, they may in 
the future.

Example -- NSTableView allows one to apply an arbitrary object, class 
irrelevant, to be used as a table column identifier:

- (int)columnWithIdentifier:(id)identifier;
- (NSTableColumn *)tableColumnWithIdentifier:(id)identifier;

Corresponding API on NSTableColumn:

- (void)setIdentifier:(id)identifier;
- (id)identifier;

"Identiefier" with an (id) type means something very different than 
"Name" with an (NSString*) type.  In particular, it means that the 
identity of the object is very likely the key to identifying table 
columns.

> That said, a subclass of unicode that is a conversion of as well as
> holds a reference to the original NSString (as Bob Ippolito suggested)
> perhaps wouldn't be so bad after all, at least for immutable strings.
> For immutable strings things still get fishy.

'For *mutable* strings things still get fishy.'?  Yes.  They certainly 
do.   Head hurts.

Right.  Off the top of your head, how much of Python breaks when 
unicode objects are passed into various random API vs. 'normal' string 
instances?   I have no idea and am hoping the number is small.

Would Bob's suggestion work in that it proxies unicode enough such that 
an instance of his class will still behave correctly in most 
situations?  Any idea of the magnitude of breakage?

I'm going to plug in Bob's implementation into the buffer_from_string() 
function I wrote.  If it does work, it would probably be useful to 
convert it into C land simply because it'll be used so often.

> Hm, here's a quick idea:
> I see that the PyUnicodeObject struct uses a seperately allocated 
> buffer
> as the backing store (as opposed to "normal" strings, where the storage
> is part of the object itself). This means that (at least in theory) can
> we actually make a _mutable_ subclass of unicode! Provided we make sure
> no hash can be taken, this might actually fly. Hm, maybe I shouldn't
> have left python-dev out of this after all...
> (This would abviously still be depending on implementation details: 
> some
> strings are hashable and others are not, and _where_ these differences
> appear may change at any time :-( )

I would think it would be a matter of ensuring that the hash is not 
cached and is recalc'd anytime it is requested.  We can do 'isDirty' 
type optimizations if it actually works.

Obviously, a mutable string as a dictionary key is generally a Bad 
Idea.  In the case of NSDictionary, I believe it makes an immutable 
copy of the inbound string.  Since NSString's -copy is effectively 
implemented as...

- copy
{
     return [self retain];
}

... the cost of the "copy" for immutable strings is negligible.

b.bum