pyobjc-dev — CVS commit notices go here

[Pyobjc-dev] O'Reilly booklet on Objective-C

[Dinu G. <gh...@da...>]

Hi,

I'm not sure if this was mentioned earlier already, but there is an
O'Reilly booklet on Objective-C which is very consise and probably
quite useful for people here:

   http://www.oreilly.com/catalog/objectcpr

Regards,

Dinu

--
Dinu C. Gherman
......................................................................
"As long as war is regarded as wicked it will always have its fascina-
tions. When it is looked upon as vulgar, it will cease to be popular."
(Oscar Wilde)

Re: [Pyobjc-dev] NSSearchPathForDirectoriesInDomains doesn't recognize YES

[Ronald O. <ous...@ci...>]

On Thursday, Feb 6, 2003, at 22:21 Europe/Amsterdam, Martina Oefelein 
wrote:
>
> I assume the problem that NSCFArray doesn't get printed as a list is a 
> temporary problem caused by the recent changes in the bridging?

Not really. This is caused by __repr__ returning the text your seeing 
instead of the result of self.description(). We do that because the 
interpreter may crash when calling description for uninitialized 
objects (the result of SomeClass.alloc()). This may be changed in the 
future (now that we can detect uninitialized objects).

Ronald

Re: [Pyobjc-dev] NSSearchPathForDirectoriesInDomains doesn't recognize YES

[Martina O. <Ma...@Oe...>]

Am Mittwoch, 05.02.03 um 10:29 Uhr schrieb Ronald Oussoren:

> Never mind, fixed in CVS.

YEP.

 >>>  
NSSearchPathForDirectoriesInDomains(NSLibraryDirectory,NSUserDomainMask, 
YES)
<NSCFArray objective-c instance 0x530560>
 >>> _[0]
'/Users/martina/Library'
 >>>  
NSSearchPathForDirectoriesInDomains(NSLibraryDirectory,NSUserDomainMask, 
NO)
<NSCFArray objective-c instance 0x160740>
 >>> _[0]
'~/Library'

I assume the problem that NSCFArray doesn't get printed as a list is a  
temporary problem caused by the recent changes in the bridging?

ciao
Martina

[Pyobjc-dev] Re: [Python-Dev] Pre-PEP: Mutable keys in dictionaries

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

Neal Norwitz wrote:

> Couldn't you add an as_key() method to NSString?  Then dict
> access would always be like:
> 
>         dict[nsstring.as_key()]

That's not my idea of transparent bridging, so no ;-)

Just

[Pyobjc-dev] Re: [Python-Dev] Pre-PEP: Mutable keys in dictionaries

[Neal N. <ne...@me...>]

On Thu, Feb 06, 2003 at 08:42:59PM +0100, Just van Rossum wrote:
> 
> [GvR]
> > Could you do this as a subclass of dict?  A subclass in Python would
> > be inefficient, but might still be good enough for your second use
> > case (the ObjC bridge).  If not, a subclass in Python might be
> > feasible -- it would be a little bit more work than integrating it
> > into dictobject.c, but you have a lot less convincing to do, and you
> > can even get it to work with Python 2.2.
> 
> But it doesn't solve our problem. We have no control over what
> dictionaries are used, either by our users directly or by the Python
> library they use. We _do_ have control over the keys that are causing
> troubles: our main problem is that we cannot rely on NSString instances
> to be immutable, yet we need the ability to use them as keys in
> (regular) dicts, just as if they were Python strings.

Couldn't you add an as_key() method to NSString?  Then dict
access would always be like:

        dict[nsstring.as_key()]

Neal

[Pyobjc-dev] Re: [Python-Dev] Pre-PEP: Mutable keys in dictionaries

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

[JvR]
> > When implemented in C in dictobject.c, this would add no overhead
> > for the "normal" case (when keys _are_ directly hashable).

[GvR]
> I have a small doubt about this claim.  Inserting code into
> PyDict_SetItem(), even if it is normally never executed, may reduce
> code locality and hence cause the code to miss the cache more often
> than before.  This *may* be addressed by rearranging the code, but
> there's a limit to that.

Ok, so this will need to be addressed somehow.

> I have a countersuggestion.
> 
> Could you do this as a subclass of dict?  A subclass in Python would
> be inefficient, but might still be good enough for your second use
> case (the ObjC bridge).  If not, a subclass in Python might be
> feasible -- it would be a little bit more work than integrating it
> into dictobject.c, but you have a lot less convincing to do, and you
> can even get it to work with Python 2.2.

But it doesn't solve our problem. We have no control over what
dictionaries are used, either by our users directly or by the Python
library they use. We _do_ have control over the keys that are causing
troubles: our main problem is that we cannot rely on NSString instances
to be immutable, yet we need the ability to use them as keys in
(regular) dicts, just as if they were Python strings.

Just

[Pyobjc-dev] Re: [Python-Dev] Pre-PEP: Mutable keys in dictionaries

[Guido v. R. <gu...@py...>]

> > Could you do this as a subclass of dict?  A subclass in Python would
> > be inefficient, but might still be good enough for your second use
> > case (the ObjC bridge).  If not, a subclass in Python might be
> > feasible -- it would be a little bit more work than integrating it
> > into dictobject.c, but you have a lot less convincing to do, and you
> > can even get it to work with Python 2.2.
> 
> But it doesn't solve our problem. We have no control over what
> dictionaries are used, either by our users directly or by the Python
> library they use. We _do_ have control over the keys that are causing
> troubles: our main problem is that we cannot rely on NSString instances
> to be immutable, yet we need the ability to use them as keys in
> (regular) dicts, just as if they were Python strings.

OK, go ahead and try to implement your idea, and report benchmarks
here.

--Guido van Rossum (home page: http://www.python.org/~guido/)

Re: [Pyobjc-dev] [ pyobjc-Bugs-681880 ] Conversion to objc string should complain about non-ASCII

[<bb...@ma...>]

Test added.

David,

     Thank you for putting forth the effort to submit bugs in the form 
of unit tests -- it very efficiently eliminates confusion.

     b.bum

[Pyobjc-dev] [ pyobjc-Bugs-681880 ] Conversion to objc string should complain about non-ASCII

[SourceForge.net <no...@so...>]

Bugs item #681880, was opened at 2003-02-06 11:42
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=681880&group_id=14534

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Eppstein (eppstein)
Assigned to: Nobody/Anonymous (nobody)
Summary: Conversion to objc string should complain about non-ASCII

Initial Comment:
In Python, a str can contain any byte sequence, and has
no specified encoding; to fix an encoding, unicode must
be used instead, and non-ascii strings can not be
converted to unicode without also providing an
encoding.  NSString is like unicode in that an encoding
is known; therefore NSString should be like unicode in
not allowing non-ascii strings to be converted to it
without providing an encoding.

However, in the current version of PyObjC, any string
can be converted to an NSString without complaint. 
This is inconsistent with Python's unicode behavior and
could lead to undetected bugs.

The following test code fails the assertion and
demonstrates the problem.

import unittest
import objc

from Foundation import NSString

class TestEncoding(unittest.TestCase):
    def testEncoding(self):
        try:
            u =
u'\xc3\xbc\xc3\xb1\xc3\xae\xc3\xa7\xc3\xb8d\xc3\xa8'
            s =
NSString.stringWithString_(u.encode('iso-8859-1'))
            self.assertEqual(u,s)
            # unlikely to be equal since stringWithString_
            # has no way of guessing the correct encoding
        except UnicodeError:
            pass
            # should get here, UnicodeError raised
            # when passing non-ascii str to objc

def suite():
    suite = unittest.TestSuite()
    suite.addTest(unittest.makeSuite(TestEncoding))
    return suite

if __name__ == '__main__':
    unittest.main( )


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=681880&group_id=14534

[Pyobjc-dev] Re: [Python-Dev] Pre-PEP: Mutable keys in dictionaries

[Guido v. R. <gu...@py...>]

> Here's a quick pre-PEP.
> 
> 
> Allow mutable objects as dictionary keys in certain cases by adding a
> new protocol. dict.__setitem__() and __contains__() would work like this
> bit of pseudo code:
> 
>   def __setitem__(self, key, value):
>       if not hashable(key):
>           if hasattr(key, "__immutable_copy__"):
>               key = key.__immutable_copy__()
>           else:
>               raise TypeError, "unhashable key"
>       ...insert value with key into dict...
> 
>   def __contains__(self, key):
>       if not hashable(key):
>           if hasattr(key, "__temporary_immutable__"):
>               key = key.__temporary_immutable__()
>           else:
>               raise TypeError, "unhashable key"
>       ...test for key membership...
> 
>   (other methods would be similar)
> 
> When implemented in C in dictobject.c, this would add no overhead for
> the "normal" case (when keys _are_ directly hashable).

I have a small doubt about this claim.  Inserting code into
PyDict_SetItem(), even if it is normally never executed, may reduce
code locality and hence cause the code to miss the cache more often
than before.  This *may* be addressed by rearranging the code, but
there's a limit to that.

I have a countersuggestion.

Could you do this as a subclass of dict?  A subclass in Python would
be inefficient, but might still be good enough for your second use
case (the ObjC bridge).  If not, a subclass in Python might be
feasible -- it would be a little bit more work than integrating it
into dictobject.c, but you have a lot less convincing to do, and you
can even get it to work with Python 2.2.

> The __temporary_immutable__ part of the protocol is needed to avoid
> unneccesary copying in those cases where the key isn't actually inserted
> into the dict, but is only used for membership testing. It would return
> a wrapper around the mutable object, defining __eq__ and __hash__. (This
> idea is stolen from the sets.py module.) If an implementer doesn't care
> about this efficiency, __temporary_immutable__ can be an alias to
> __immutable_copy__.
> 
> 
> Use Cases:
> 
> - sets.py could be written more efficiently and/or could be more easily
>   be rewritten in C.
> 
> - Again, the troubles of bridging Python to Objective-C have triggered
>   this idea. Due to the nature of Objective-C in general, and Cocoa in
>   particular, we can never be sure beforehand whether a string is
>   mutable or not. We can detect mutability at runtime, but depending on
>   this is dangerous as it exposes an implementation detail that may
>   change between releases of _any_ API that returns strings. Therefore
>   code that works in one setup may break in another, or even in the the
>   same setup after an arbitrary library upgrade, simply because an API
>   suddenly returns a mutable string where it didn't before. Yes this
>   sucks, but it's the way it is. <Add link to post from bbum explaining
>   this situation in detail>
> 
> 
> Backwards compatibilty:
> 
> 100%.
> 
> Overhead added
> 
> None
> 
> 
> Implementation
> 
> There's quite a bit of code duplication in those areas of dictobject.c
> that matter for this proposal, so implementing it will take longer than
> the 10 minutes I originally estimated <wink>. Perhaps this is a good
> opportunity to refactor these bits into inline functions? Not being a C
> guru I can't judge whether this is possible or desirable with the set of
> compilers that Python must be built with.

You can't rely on inline.  OTOH, GCC -O3 often inlines static
functions without needing a hint.

--Guido van Rossum (home page: http://www.python.org/~guido/)

[Pyobjc-dev] Pre-PEP: Mutable keys in dictionaries

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

Here's a quick pre-PEP.


Allow mutable objects as dictionary keys in certain cases by adding a
new protocol. dict.__setitem__() and __contains__() would work like this
bit of pseudo code:

  def __setitem__(self, key, value):
      if not hashable(key):
          if hasattr(key, "__immutable_copy__"):
              key = key.__immutable_copy__()
          else:
              raise TypeError, "unhashable key"
      ...insert value with key into dict...

  def __contains__(self, key):
      if not hashable(key):
          if hasattr(key, "__temporary_immutable__"):
              key = key.__temporary_immutable__()
          else:
              raise TypeError, "unhashable key"
      ...test for key membership...

  (other methods would be similar)

When implemented in C in dictobject.c, this would add no overhead for
the "normal" case (when keys _are_ directly hashable).

The __temporary_immutable__ part of the protocol is needed to avoid
unneccesary copying in those cases where the key isn't actually inserted
into the dict, but is only used for membership testing. It would return
a wrapper around the mutable object, defining __eq__ and __hash__. (This
idea is stolen from the sets.py module.) If an implementer doesn't care
about this efficiency, __temporary_immutable__ can be an alias to
__immutable_copy__.


Use Cases:

- sets.py could be written more efficiently and/or could be more easily
  be rewritten in C.

- Again, the troubles of bridging Python to Objective-C have triggered
  this idea. Due to the nature of Objective-C in general, and Cocoa in
  particular, we can never be sure beforehand whether a string is
  mutable or not. We can detect mutability at runtime, but depending on
  this is dangerous as it exposes an implementation detail that may
  change between releases of _any_ API that returns strings. Therefore
  code that works in one setup may break in another, or even in the the
  same setup after an arbitrary library upgrade, simply because an API
  suddenly returns a mutable string where it didn't before. Yes this
  sucks, but it's the way it is. <Add link to post from bbum explaining
  this situation in detail>


Backwards compatibilty:

100%.


Overhead added

None


Implementation

There's quite a bit of code duplication in those areas of dictobject.c
that matter for this proposal, so implementing it will take longer than
the 10 minutes I originally estimated <wink>. Perhaps this is a good
opportunity to refactor these bits into inline functions? Not being a C
guru I can't judge whether this is possible or desirable with the set of
compilers that Python must be built with.


Just

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

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

Bill Bumgarner wrote:

> In general, I would like to see Python move in the direction of 
> supporting <character buffers> in an analagous/interchangeable fashion 
> with <string>.   This would make integration with external tools a lot 
> easier.

To a large extent this already works for 8-bit strings, but I don't see
an easy solution for unicode that doesn't depend on a specific format of
the backing store.


I'll try to write a proposal regarding __immutablecopy__, which btw.
needs a __temporaryimmutable__ counterpart for efficient membership
testing (this would return a thin wrapper what would compare and hash
equally to the real thing, yet no copy is made). This latter idea I just
saw in sets.py: neat.

Just

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

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

That makes a lot of sense.

In general, I would like to see Python move in the direction of 
supporting <character buffers> in an analagous/interchangeable fashion 
with <string>.   This would make integration with external tools a lot 
easier.

A part of that is doing exactly what you have indicated below -- when a 
string must be constant and there is a question as to whether or not 
the backing store for the string is mutable, provide a mechanism via 
which an immutable copy can be created.

Nice.

b.bum

On Wednesday, Feb 5, 2003, at 17:34 US/Eastern, Just van Rossum wrote:
> Just van Rossum wrote:
>
>> Python doesn't do anything special to "inbound" keys, it simply barfs
>> when the key isn't hashable.
>
> Here's an idea: we could propose a new protocol for dicts that would
> work like this:
>
>   def __setitem__(self, key, value):
>       if not hashable(key):
>           if hasattr(key, "__immutablecopy__"):
>               key = key.__immutablecopy__()
>           else:
>               raise TypeError, "unhashable key"
>       ...insert value with key into dict...
>
> This might actually solve our problem nicely. Soonest for 2.3, though,
> and even then we need to hurry.
>
> Just

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

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

Just van Rossum wrote:

> Python doesn't do anything special to "inbound" keys, it simply barfs
> when the key isn't hashable.

Here's an idea: we could propose a new protocol for dicts that would
work like this:

  def __setitem__(self, key, value):
      if not hashable(key):
          if hasattr(key, "__immutablecopy__"):
              key = key.__immutablecopy__()
          else:
              raise TypeError, "unhashable key"
      ...insert value with key into dict...

This might actually solve our problem nicely. Soonest for 2.3, though,
and even then we need to hurry.

Just

Re: [Pyobjc-dev] NSString & mutability

[Lele G. <le...@se...>]

>>>>> On Wed, 5 Feb 2003 21:12:08 +0100, Ronald Oussoren <oussoren@cistro=
n.nl> said:

    Ronald> What I've done:

    Ronald> pythonify_c_value, case _C_ID, is now a lot simpler than
    Ronald> it was before: It calls __pyobjc_PythonObject__. End of
    Ronald> story.

Very very nice!

I'm sadly short of time to contribute, but I'm astonished seeing all
you bringing PyObjC this far! ;-)

G'night,
ciao, lele.
--=20
nickname: Lele Gaifax	| Quando vivr=F2 di quello che ho pensato ieri
real: Emanuele Gaifas	| comincer=F2 ad aver paura di chi mi copia.
email: le...@se...	|		-- Fortunato Depero, 1929.

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

[Guido v. R. <gu...@py...>]

> On Wednesday, Feb 5, 2003, at 10:52 US/Eastern, Guido van Rossum wrote:
> > In my experience almost no Python code depends on this property, and
> > it seems to be the most problematic one.  So why is this a
> > requirement?

[BBum]
> Because we are using Python to glue together other object oriented 
> frameworks-- Apple's and third party's-- for which we do not have 
> control over said behavior.
> 
> Sometimes an object is just an object and those frameworks insist on 
> the same object-- same identifier/address-- coming out that went in.
> 
> As Just pointed out, my original example wasn't as clear as it could 
> have been.   If a String object comes out of the alien-to-python world 
> and is later sent from python back into the alien-to-python runtime, 
> the same String object-- the same id()-- must be sent back.

Ah.  I still don't know what you call "alien" and what you call
"native".  But I think that I understood your original example as
going the other direction (Python -> ObjC -> Python) while the issue
really is ObjC -> Python -> ObjC.

> > If you can live with only using Unicode strings (even when all they
> > contain is ASCII or Latin-1 values), I think subclassing Unicode might
> > be the way to go.
> 
> Right.  I believe that is the path will we go down.
> 
> > I don't have time to dig deeper into this.  But if you think a small
> > change to Python can make life easier for you, I expect we'll be happy
> > to implement it, as long as it doesn't make life harder for Python
> > developers.
> 
> I can think of a couple of changes to Python that would be potentially 
> quite helpful in this situation.
> 
> Specifically:
> 
>      - ability to have weak references to string objects [and unicode 
> objects].   Since we can make arbitrary object associations and 
> re-associations when crossing the bridge between environments, I 
> believe weakref would allow us to maintain a reference map as long as 
> we could grab the 'string is now going away' callback to update the 
> weakref map when the string is deallocated

Would you be okay with only weak refs to unicode objects?

Either way, you have to start by submitting a patch (referring to this
thread).

>      - ability to subclass string objects or the ability to add a hunk 
> of data-- the reference to the 'alien' string object-- to any string 
> object.

You can do that in C, if you know how.  The trick is to set
tp_itemsize to 4 bytes extra, and then index from the end (rounding
down).  See how _PyObject_GetDictPtr() works when the dict offset is
negative (in practice it will always be -4).

> Either one would work equally as well... whether or not they are easy 
> to do, I have not a clue.

Who knows.

--Guido van Rossum (home page: http://www.python.org/~guido/)

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

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

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

On Wednesday, Feb 5, 2003, at 10:52 US/Eastern, Guido van Rossum wrote:
> In my experience almost no Python code depends on this property, and
> it seems to be the most problematic one.  So why is this a
> requirement?

Because we are using Python to glue together other object oriented 
frameworks-- Apple's and third party's-- for which we do not have 
control over said behavior.

Sometimes an object is just an object and those frameworks insist on 
the same object-- same identifier/address-- coming out that went in.

As Just pointed out, my original example wasn't as clear as it could 
have been.   If a String object comes out of the alien-to-python world 
and is later sent from python back into the alien-to-python runtime, 
the same String object-- the same id()-- must be sent back.

> If you can live with only using Unicode strings (even when all they
> contain is ASCII or Latin-1 values), I think subclassing Unicode might
> be the way to go.

Right.  I believe that is the path will we go down.

> I don't have time to dig deeper into this.  But if you think a small
> change to Python can make life easier for you, I expect we'll be happy
> to implement it, as long as it doesn't make life harder for Python
> developers.

I can think of a couple of changes to Python that would be potentially 
quite helpful in this situation.

Specifically:

     - ability to have weak references to string objects [and unicode 
objects].   Since we can make arbitrary object associations and 
re-associations when crossing the bridge between environments, I 
believe weakref would allow us to maintain a reference map as long as 
we could grab the 'string is now going away' callback to update the 
weakref map when the string is deallocated

     - ability to subclass string objects or the ability to add a hunk 
of data-- the reference to the 'alien' string object-- to any string 
object.

Either one would work equally as well... whether or not they are easy 
to do, I have not a clue.

b.bum

Re: [Pyobjc-dev] Uh... this will sound stupid.

[Ronald O. <ous...@ci...>]

On Thursday, Feb 6, 2003, at 08:53 Europe/Amsterdam, Andre Garzia wrote:

> Hi folks,
>
> is that i just don't know how to use CVS... i want to update my pyObjC 
> with the new templates and stuff...

This is explained on sourceforge, but anyway... The first time you 
download the sources you do:
	$ cvs -d ':pserver:ano...@cv...:/cvsroot/pyobjc' login
	$ cvs -d ':pserver:ano...@cv...:/cvsroot/pyobjc' co 
pyobjc

The first command will ask for a password, use an empty password. The 
second command will create a directory 'pyobjc' in the current 
directory.

If you want to update your tree later on you can do 'cvs update' from 
the root of the checked out tree.

Ronald

Re: [Pyobjc-dev] NSString & mutability

[<bb...@ma...>]

On Wednesday, Feb 5, 2003, at 15:12 US/Eastern, Ronald Oussoren wrote:
> BTW. Is anyone using the Objective-C style interface to Python objects 
> as defined by OC_PythonObject (e.g. [pyobject1 numberAdd:pyobject2])? 
> I'd like to remove this interface as most interesting types are, or 
> will be, proxied using classes with a Cocoa-style interface anyway.

I don't believe so.   Also, OC_PythonString.[hm] was not being used 
either, but I'm now using it for the String proxy I have put together 
-- don't bother removing it.   It still needs clean up and may need 
adjusting after your changes are committed.

The other changes sound like a grand improvement.

b.bum

Re: [Pyobjc-dev] Uh... this will sound stupid.

[<bb...@ma...>]

On Thursday, Feb 6, 2003, at 02:53 US/Eastern, Andre Garzia wrote:
> Hi folks,
>
> is that i just don't know how to use CVS... i want to update my pyObjC 
> with the new templates and stuff...

Not a problem -- it is confusing until you have done it about a 
bazillion times

First, you need to login.  From the directory into which you want the 
source checked out:

cvs -d:pserver:ano...@cv...:/cvsroot/pyobjc login

It will ask for a password.  Just hit return.  Then, to check out the 
source:

cvs -z3 -d:pserver:ano...@cv...:/cvsroot/pyobjc co 
pyobjc

You will also need libFFI if you want to use the new templates [there 
are non-FFI related changes in the repository upon which the new 
templates rely].  Grab libFFI source from:

http://sourceforge.net/project/showfiles.php?group_id=14534

Installation instructions are contained within.   We really ought to 
roll up a binary tarball of libFFI.  Ideally, maybe it could be built 
in a fashion such that it could be untarred into the pyobjc source tree?

b.bum

Re: [Pyobjc-dev] NSString & mutability

[Ronald O. <ous...@ci...>]

I've implemented a scheme that was mentioned on the list a while back 
during the discusion of posing and which should make experimenting with 
the various proposed solutions a little easier (mostly for the creation 
of a Python representation of Objective-C instances, wrapping Python 
strings using a custom proxy object seems to be rather 
uncontroversial). Not only that, it also makes the bridge code slightly 
simpler.

What I've done:

* All custom proxy-objects (OC_PythonObject and friends) implement 
__pyobjc_PythonObject__. This
   method returns a new reference to the wrapped Python object
* All Python subclasses of Objective-C classes also implement this 
method
* And last but not least, a category on NSObject also defines this 
method (both as an instance and
   as a class method). Both return a proxy for self (the instance of the 
class).

pythonify_c_value, case _C_ID, is now a lot simpler than it was before: 
It calls __pyobjc_PythonObject__. End of story.

This works rather well, and it is quite easy to add support for special 
treatment for some classes, I've done so for NSString and NSNumber: 
Just implement a category implementing __pyobjc_PythonObject__
and your done.

The __pyobjc_PythonObject__ implementation for NSNumber converts back 
to the corresponding Python number, which solves the bug in 
test_nsundomanager (the int->NSNumber problem mentioned by David). The 
functions in Foundation.Conversions don't like this change (obviously). 
test_nsnumber also fails, because NSNumber instances are no longer 
visible from Python.

The __pyobjc_PythonObject__ implementation for NSString exactly mirrors 
the code that is currently in pythonify_c_value. Feel free to 
experiment with that code :-)

BTW. Is anyone using the Objective-C style interface to Python objects 
as defined by OC_PythonObject (e.g. [pyobject1 numberAdd:pyobject2])? 
I'd like to remove this interface as most interesting types are, or 
will be, proxied using classes with a Cocoa-style interface anyway.

I'll check these changes in later on this evening (it is evening over 
here in Europe :-), after cleaning up some issues with other pending 
changes.

Ronald

[Pyobjc-dev] Uh... this will sound stupid.

[Andre G. <so...@ma...>]

Hi folks,

is that i just don't know how to use CVS... i want to update my pyObjC=20=

with the new templates and stuff...

Andre Alves Garzia =EF=A3=BF 2002 =EF=A3=BF BRAZIL
mailto://so...@ma...

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

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

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

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

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.

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 :-( )

Just