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

[Just v. R. <ju...@le...>]

Bill Bumgarner wrote:

> Example -- NSTableView allows one to apply an arbitrary object, class=20
> irrelevant, to be used as a table column identifier:
>=20
> - (int)columnWithIdentifier:(id)identifier;
> - (NSTableColumn *)tableColumnWithIdentifier:(id)identifier;
>=20
> Corresponding API on NSTableColumn:
>=20
> - (void)setIdentifier:(id)identifier;
> - (id)identifier;
>=20
> "Identiefier" with an (id) type means something very different than=20
> "Name" with an (NSString*) type.  In particular, it means that the=20
> identity of the object is very likely the key to identifying table=20
> columns.

It seems that solving the mutable vs. immutable issue by means of a
wrapper/proxy issue will also solve this one for NSStrings.

However, the NSTableView doco has this to say:

"""
columnWithIdentifier:=20

- (int) columnWithIdentifier: (id) anObject=20
Returns the index of the first column in the receiver whose identifier
is equal to anObject , when compared using isEqual: , or =AD1 if no
columns are found with the specified identifier.=20
"""

Note the "when compared using isEqual". So it appears the API isn't as
broken as you suggest...

Still, we write Python code. There will _always_ be Cocoa things that
are hard or even impossible to do from Python. We have to make
compromises, often choosing between "model Cocoa as closely as possible
in Python" and "make Cocoa a pleasure to work with from Python". Unless
there are serious flaws (such as with mutable strings), I think we
should generally choose for convenience.

One such compromise would be "when passing NSNumber instances across the
bridge, the object identity will not be preserved". It is awfully silly
to _wrap_ NSNumbers. And there's no NSMutableNumber, is there <0.5
wink>?

We write in Python because it gives us a head-start compared to people
using Obj-C or C or C++ or Java. Let's not hurt ourselves by sticking
too close to theoretical correctness.

> > 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.
>=20
> 'For *mutable* strings things still get fishy.'?=20

Yes, that was a brainfart.

> Yes.  They certainly do.   Head hurts.
>=20
> Right.  Off the top of your head, how much of Python breaks when=20
> unicode objects are passed into various random API vs. 'normal' string=20
> instances?=20

That works reasonable well, and actually has a much greater chance of
working well than creating our own string-like type or unicode-like
type. However, there are objects and calls that are not unicode aware.
Eg. writing a unicode string to a file currently only works if it only
contains pure 7-bit ascii characters. (There is an encoding aware file
object replacement available, but it needs to imported separately, see
codecs.open()).

We could wrap NSString instances in a str subclass or a unicode subclass
depending on whether the NSString is 7-bit clean. There is little point
(apart from simplicity) in _always_ using a unicode subclass, as they
will cause the exact same surprises (as mentioned above).

>  I have no idea and am hoping the number is small.

Since NSStrings can _always_ contain unicode, I think we should assume
using unicode strings is fine.

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

(Assuming you mean his suggestion to subclass unicode) I think this has
a good chance of working really well.

> > Hm, here's a quick idea:
> > [creating a mutable subclass of unicode]
>=20
> I would think it would be a matter of ensuring that the hash is not=20
> cached and is recalc'd anytime it is requested.  We can do 'isDirty'=20
> type optimizations if it actually works.

Doesn't work: it's a requirement (at least for Python dicts, but I think
it's a generic hash table requirement) that an object's hash value
doesn't change while it's used as a key. Hence only immutable objects
are allowed as dict keys. (There's a minor exception to this: objects
that don't define __eq__ (and/or __cmp__, I'm not sure about the exact
details) can still be used as keys: they will be compared by id, and
hash(suchAnObject) returns the same as id(suchAnObject.)

> Obviously, a mutable string as a dictionary key is generally a Bad=20
> Idea.  In the case of NSDictionary, I believe it makes an immutable=20
> copy of the inbound string.  Since NSString's -copy is effectively=20
> implemented as...
>=20
> - copy
> {
>      return [self retain];
> }
>=20
> .... the cost of the "copy" for immutable strings is negligible.

It does still brings the dependency on implementation details to Python:
_some_ NSStrings can be used as keys in Python dicts and others won't.
Python doesn't do anything special to "inbound" keys, it simply barfs
when the key isn't hashable.

Shall we call this the "fragile mutability" syndrome? It's a darn ugly
corner of Cocoa if you ask me :-(.

Just