pyobjc-dev — CVS commit notices go here

[Pyobjc-dev] Re: [ pyobjc-Bugs-679748 ] NSMutableString gets converted to Python string

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

On Monday, Feb 3, 2003, at 15:26 US/Eastern, SourceForge.net wrote:
>> Comment By: Just van Rossum (jvr)
> Date: 2003-02-03 21:26
>
> Message:
> Logged In: YES
> user_id=92689
>
> How's this: let's _not_ convert any NS{Mutable}String as an 
> experiment, and see what it breaks in the Examples area and in our own 
> respective code bases code. We can always go back and do it 
> differently.

This is my next Train Hack(tm) for the ride home this evening.  I'm 
going to implement two things:

- an OC_NSString subclass of NSString that can encapsulate a python 
string an an NSString compatible fashion

- a python object that provides a character buffer style interface to 
the contents of an NSString.

The former *should* be easy.  The latter will be difficult, but I have 
experience with the character buffer APIs from doing the 
NSData/NSBitmapImageRep API support.

Thank GOODNESS for unit tests.   It is going to be *really* easy to get 
a feel for what breaks.

If anyone has a test rolling around your head that you'd think would be 
a good thing to support/do, please whip off a test.  Just copy one of 
the test cases that are already in Lib/Foundation/test [has more tests 
than the other two modules] and modify it for your needs.   I don't 
really care if the test passes or fails-- but, if it fails, make sure 
it fails because it is demonstrating something you *want* to work.

b.bum

Re: [Pyobjc-dev] Auto bridging instances by conversion

[Bob I. <bo...@re...>]

On Monday, Feb 3, 2003, at 15:18 America/New_York, Just van Rossum 
wrote:

> Bob Ippolito wrote:
>
>> re.match is obviously *finding* a match, but it's just not building
>> the groups right.  I'll file a bug on sourceforge.
>
> It bahaves the same with a regular string, though:
>
>>>> re.match("la", "lalala").groups()
>   ()
>
> I think the .groups() method only returns explicit groups, and not
> group(0).

My bad, you're right.  I sure am full of mistakes today.  It's 
obviously been far too long since I've used the re module; I think I've 
used re.match two or three times in the past year.. Kind of strange 
that when I was doing @P$e%r&l I'd use regular expressions all over the 
place, it's probably because PyString has enough features to make re 
unnecessary in most situations.

-bob

Re: [Pyobjc-dev] Auto bridging instances by conversion

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

Bob Ippolito wrote:

> re.match is obviously *finding* a match, but it's just not building
> the groups right.  I'll file a bug on sourceforge.

It bahaves the same with a regular string, though:

  >>> re.match("la", "lalala").groups()
  ()

I think the .groups() method only returns explicit groups, and not
group(0).

Just

Re: [Pyobjc-dev] Auto bridging instances by conversion

[Bob I. <bo...@re...>]

On Monday, Feb 3, 2003, at 14:19 America/New_York, Just van Rossum 
wrote:

> Bob Ippolito wrote:
>
>>> Not converting can also be problematic: What if you pass the
>>> NSString to an extension-function that expects a string (like
>>> open), unless these get changed to also accept NSStrings you'll
>>> have to perform manual conversion from NSString to a python string.
>>
>> Say NSString acts like 100% like UserString (i.e. implements __str__
>> and such), wouldn't PyArg_ParseTuple(AndKeywords) do The Right Thing?
>
> I have no idea how well this can work, but UserString seems to be a
> pain:

Well, that sucks.  I'd consider that a bug.  With 2.2's unification of 
types and classes you SHOULD be able to do this. :(

I guess after re-reading http://www.python.org/2.2/descrintro.html it 
comes down to the equivalent of:

"""
However, our __getitem__() method is not used for variable access by 
the interpreter:

     >>> exec "print foo" in a
     Traceback (most recent call last):
       File "<stdin>", line 1, in ?
       File "<string>", line 1, in ?
     NameError: name 'foo' is not defined
     >>>

Why doesn't this print 0.0? The interpreter uses an internal function 
to access the dictionary, which bypasses our __getitem__() override. I 
admit that this can be a problem (although it is only a problem in this 
context, when a dict subclass is used as a locals/globals dictionary); 
it remains to be seen if I can fix this without compromising 
performance in the common case.
"""

I haven't looked at the internals of the bridge, but what about 
something like this (imagine B is NSString, and A is 
MyPyStringCruftForNSString)

 >>> class A(str):
...   def __new__(clazz, myObject):
...     s = str.__new__(clazz, repr(myObject))
...     s._obj = myObject
...     return s
...   def __getattr__(self, attr):
...     return getattr(self._obj, attr)
...
 >>> class B(object):
...   blah = 1
...   blahblah = 2
...
 >>> a = A(B())
 >>> a
'<__main__.B object at 0x1673e0>'
 >>> a.blah
1

Unfortunately this _still_ won't work with re.match (at least in 
Jaguar's 2.2.0, I'd consider this a bug in re.match), but it *does* 
work with open()

 >>> class C(str):
...   def length(self):
...     return len(self)
...
 >>> c = C('lalala')
 >>> c.length()
6
 >>> re.match('la', c)
<_sre.SRE_Match object at 0x159750>
 >>> _.groups()
()
 >>> re.match('moo', c)
 >>>

re.match is obviously *finding* a match, but it's just not building the 
groups right.  I'll file a bug on sourceforge.

This is obviously not a solution for NSMutableString though, but it 
might make the bridge for static strings a little snazzier (maintain 
all original functionality).. you don't lose the NSString object, but 
you gain *just about* full PyString magic.. anything that breaks you 
can 'fix' with str(myInstance)

-bob

[Pyobjc-dev] [ pyobjc-Bugs-679748 ] NSMutableString gets converted to Python string

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

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Just van Rossum (jvr)
Assigned to: Nobody/Anonymous (nobody)
Summary: NSMutableString gets converted to Python string

Initial Comment:
Regardless of the issue whether NSStrings should be converted at all, NSMutableString definitely must not be converted to a Python string when calling into Python. David Eppstein posted this test case to the list:

# test ability to use NSMutableString

from Foundation import NSObject, NSMutableString

class TestUndoInt (NSObject):
    def init(self):
        self.string = NSMutableString.stringWithCapacity_(20)
        self.string.setString_("initial")

x = TestUndoInt.alloc().init()
assert(str(x.string) == 'initial')


This fails with an AttributeError "setString_" as self.string was converted to a Python string.

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

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

[Pyobjc-dev] test for integer handling by undoManager

[David E. <epp...@ic...>]

# test ability of int argument to pass through undo and then
# be used as parameter to another routine expecting an int
#
# the actual routine I want to use is
# NSTableView.editColumn_row_withEvent_select_
# but that involves setting up a UI; instead use NSIndexSpecifier

from Foundation import NSObject, NSUndoManager, NSIndexSpecifier

class TestUndoInt (NSObject):
    undo = NSUndoManager.alloc().init()
    idx = NSIndexSpecifier.alloc().init()
    idx.setIndex_(0)

    def test(self,i):
        self.undo.prepareWithInvocationTarget_(self).test(self.idx.index())
        self.idx.setIndex_(i)

# test that undo works
x = TestUndoInt.alloc().init()
x.test(3)
assert(x.idx.index() == 3)
x.undo.undo()
assert(x.idx.index() == 0)

--
David Eppstein       UC Irvine Dept. of Information & Computer Science
epp...@ic... http://www.ics.uci.edu/~eppstein/

Re: [Pyobjc-dev] Auto bridging instances by conversion

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

On Monday, Feb 3, 2003, at 14:15 US/Eastern, David Eppstein wrote:
> Shouldn't the following work?  I get an exception, str has no 
> setString_ method... I was hoping to use NSMutableString for my 
> testing of int undo handling, since it is simpler to set up than the 
> NSTableView method where I ran across the int issue, but I guess I'll 
> have to look for something else...
>
>
... test case deleted ...

First, thank you for the test case.

That particular behavior is expected (but maybe not correct-- your test 
case nicely summates what is currently being debated in the rest of 
this thread).

The bridge automatically converts any instance of NSString going from 
ObjC->Python to a Python String.  End result is this...

            self.string = NSMutableString.stringWithCapacity_(20)

... causes self.string to be a Python string [likely of length 0].

b.bum

Re: [Pyobjc-dev] Auto bridging instances by conversion

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

Bob Ippolito wrote:

> > Not converting can also be problematic: What if you pass the
> > NSString to an extension-function that expects a string (like
> > open), unless these get changed to also accept NSStrings you'll
> > have to perform manual conversion from NSString to a python string.
> 
> Say NSString acts like 100% like UserString (i.e. implements __str__
> and such), wouldn't PyArg_ParseTuple(AndKeywords) do The Right Thing?

I have no idea how well this can work, but UserString seems to be a
pain:

  Python 2.3a1 (#106, Feb  2 2003, 19:33:52) 
  [GCC 3.1 20020420 (prerelease)] on darwin
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import re
  >>> from UserString import UserString
  >>> s = UserString("lalalala")
  >>> s
  'lalalala'
  >>> repr(s)
  "'lalalala'"
  >>> open(s)
  Traceback (most recent call last):
    File "<stdin>", line 1, in ?
  TypeError: coercing to Unicode: need string or buffer, instance found
  >>> re.match("la", s)
  Traceback (most recent call last):
    File "<stdin>", line 1, in ?
    File "/usr/local/lib/python2.3/sre.py", line 132, in match
      return _compile(pattern, flags).match(string)
  TypeError: expected string or buffer
  >>> 


Just

Re: [Pyobjc-dev] Auto bridging instances by conversion

[David E. <epp...@ic...>]

Shouldn't the following work?  I get an exception, str has no setString_ 
method... I was hoping to use NSMutableString for my testing of int undo 
handling, since it is simpler to set up than the NSTableView method where I 
ran across the int issue, but I guess I'll have to look for something 
else...


# test ability to use NSMutableString

from Foundation import NSObject, NSMutableString

class TestUndoInt (NSObject):
    def init(self):
        self.string = NSMutableString.stringWithCapacity_(20)
        self.string.setString_("initial")

x = TestUndoInt.alloc().init()
assert(str(x.string) == 'initial')

--
David Eppstein       UC Irvine Dept. of Information & Computer Science
epp...@ic... http://www.ics.uci.edu/~eppstein/

Re: [Pyobjc-dev] Auto bridging instances by conversion

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

bb...@ma... wrote:

> Unfortunately, it is not that simple; not that black/white.

Is it ever? ;-)

> It is quite possible-- used to be common, but I'm seeing it less and 
> less often-- for a method that is declared as....
> 
> - (NSString *) fooBar;
> 
> .... to actually return an instance of NSMutableString.   Contrary to 
> initial belief, this is not a bug.   NSString is a superclass of 
> NSMutableString-- the declared return type tells the developer that 
> they should treat the string as immutable and the developer must do so 
> unless they either either want to put up with a bunch of compiler 
> warnings or do an evil downcast for an object not their own.

I recently learned about this but hadn't thought of it in this context.
I don't assume the _declared_ return type is available at runtime? If
so, we could use that, but I guess it isn't.

> As such, we really can't limit conversion of strings to just the 
> immutable strings while leaving the mutable strings alone.  The end 
> result would be vast amounts more confusion than we currently have -- 

Where the value of "vast" depends on how frequently this pattern
actually occurs in the call you use.

> there are situations where a method may return an NSString* instance 
> some of the time and NSMutableString* instances at other times.
> 
> However, I believe that *not* converting NSString and using a bridging 
> mechanism similar as to what is used for NSArray and NSDictionary may 
> work quite well.

Hm, perhaps you're right.

> --
> 
> Python -> ObjC
> 
> This is easy.   Simply create a subclass of NSString that
> encapsulates an instance of a Python string [or character buffer] and
> implements the appropriate primitive methods.   From there, it should
> "just work". No need to also provide a subclass of NSMutableString
> because Python strings are always immutable -- correct?

Correct.

> --
> 
> ObjC -> Python
> 
> A more difficult case because there isn't [yet] a <string> base type
> to inherit from that is used for all 'are you a string' testing.
> 
> However, if one were to implement a Python module that providing a 
> <character buffer> type API that wraps around an NSString [immutable 
> only] instance, it appears that most of the Python core would handle 
> that particular argument just fine.
> 
> Example:   the open() or file() functions would work just fine as
> long as the inbound object for the <name> argument is a character
> buffer (as that function-- open is just an alias for file anyway--
> uses 'et' as the parse format for PyArgs_ParseTupleAndKeywords()).

But what about (say) regular expressions on unicode strings?

> --
> 
> Furthermore, the (id) of an object-- the address contained in self--
> is often used as a meaningful identifier.   If a developer places an
> object into a container-- a dictionary or an array-- they expect to
> retrieve the exact same instance-- the same self pointer-- upon
> retrieving that object.

Such an assumption is only safe if the code works directly with these
collection objects. I don't think any code can be called sane it it
stops working when it receives an object from elsewhere that has a
different id than it expects.

> In this context, that an object is an (int) and the first 100 ints are 
> singletons is completely irrelevant.   Consider the object in pure OO 
> terms-- it is just an object contained in a collection, its type does 
> not matter.

I don't see why the id should matter either. From a Python perspective,
all that matters is that the two objects compare and hash equally. Sure,
comparison is _cheaper_ when the two objects have the same id, but would
stuff actually _break_ if the id's weren't the same? That's just sick.

> In my experience with bridging-- many years and going between a
> number of different languages--

(Do you have a macro for that sentence? ;-)

> conversion always turns out to be a
> headache. Sometimes, there is more benefit from doing the conversion
> than there would be from not doing so,  but that is *rarely* the case
> and there is *always* a price to be paid for doing the conversion.
> 
> Do not discount the performance hit -- it can be truly nasty.  

Yet Python is _primarily_ about convenience. Efficiency is secondary.
Using Python comes at a price, and every bridge causes some overhead.
For example passing a C string to Python *always* causes the string to
be copied. I don't see what's so inherently bad at treating NSStrings
the same way.

Regarding numbers: from ObjC -> Python there will be hardly a difference
between conversion and wrapping: for both cases a new object needs to be
allocated (except when the number is between -1 and 99 in which case
conversion is _cheaper_).

It's _great_ that wrapped NSArrays work much like lists but aren't, and
I wouldn't want it any other way, but a number should really be a
number.

> In the context of the Java<->ObjC bridge, the fact that
> Strings<->NSStrings conversions occur means that bridged code using
> ObjC collections is so astoundingly slow and memory inefficient as to
> require the developer to often change the design patterns radically
> (at least, that *was* the case with the WO 4.5 / OS X PB and prior
> bridge -- don't know if it still is, but I imagine it likely is).  

I don't buy this: why use Foundation collections on a large scale in a
_Python_ app? The situation where *both* Python and ObjC need to access
a dict in tight loops sounds fairly unlikely. You can choose
NSDictionary or dict depending on whether Python or ObjC will need to
access it most frequently.

Just

Re: [Pyobjc-dev] Auto bridging instances by conversion

[Bob I. <bo...@re...>]

On Monday, Feb 3, 2003, at 11:21 America/New_York, Ronald Oussoren 
wrote:

>
> On Monday, Feb 3, 2003, at 16:58 Europe/Amsterdam, Bob Ippolito wrote:
>
>>
>> On Monday, Feb 3, 2003, at 10:30 America/New_York, Just van Rossum 
>> wrote:
>>
>>> bb...@ma... wrote:
>>>
>>>> The fact that NSString<->PyString are converted is a bug --
>>>
>>> To me it isn't, it's what I call "transparent". This feature is
>>> absolutely a _pleasure_ to work with.
>>
>> It's what I call a "real pain in the ass", at least when 
>> NSMutableString gets bridged into a PyString.
> A real argument for not doing the conversion!
>
> Not converting can also be problematic: What if you pass the NSString 
> to an extension-function that expects a string (like open), unless 
> these get changed to also accept NSStrings you'll have to perform 
> manual conversion from NSString to a python string.

Say NSString acts like 100% like UserString (i.e. implements __str__ 
and such), wouldn't PyArg_ParseTuple(AndKeywords) do The Right Thing?

>>
>> Why can't we wrap the NSString class cluster with some cruft that 
>> makes it pythonic instead of converting it to something that it 
>> wasn't?  There is absolutely no namespace clash between NSString and 
>> PyString, with the added bonus that NSString can do just about 
>> everything that PyString can with one line of code or less.
>
> The 'problem' with NSString is that its interface is much more 
> powerfull than that of python strings (the word cruft springs to mind 
> when seeing methods like stringByAbbreviatingWithTildeInPath).

Well since there is no namespace clash, NSString doesn't lose those.  
If PyArg_ParseTuple does The Right Thing, this (useless code) should 
work:
myDesktop = NSString('~/Desktop').stringByAbbreviatingWithTildeInPath()
myHomedir, myDesktop = os.path.split(myDesktop)

>
> In case anyone cares: I (still) haven't made made my mind up on 
> whether automaticly converting values is a usefull feature or not. 
> There are to many irritating 'features' on either solution (converting 
> or wrapping).

I'm really against converting NSMutableANYTHING.  I can think of at 
least one AppKit class where you can get a NSMutableString (perhaps 
it's a subclass of) as an rval to some method, where you change that 
NSMutableString and the view changes its contents based upon any 
changes you make to that NSMutableString (without having to call any 
additional methods).

-bob

Re: [Pyobjc-dev] Auto bridging instances by conversion

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

Unfortunately, it is not that simple; not that black/white.

It is quite possible-- used to be common, but I'm seeing it less and 
less often-- for a method that is declared as....

- (NSString *) fooBar;

... to actually return an instance of NSMutableString.   Contrary to 
initial belief, this is not a bug.   NSString is a superclass of 
NSMutableString-- the declared return type tells the developer that 
they should treat the string as immutable and the developer must do so 
unless they either either want to put up with a bunch of compiler 
warnings or do an evil downcast for an object not their own.

As such, we really can't limit conversion of strings to just the 
immutable strings while leaving the mutable strings alone.  The end 
result would be vast amounts more confusion than we currently have -- 
there are situations where a method may return an NSString* instance 
some of the time and NSMutableString* instances at other times.

However, I believe that *not* converting NSString and using a bridging 
mechanism similar as to what is used for NSArray and NSDictionary may 
work quite well.

--

Python -> ObjC

This is easy.   Simply create a subclass of NSString that encapsulates 
an instance of a Python string [or character buffer] and implements the 
appropriate primitive methods.   From there, it should "just work".   
No need to also provide a subclass of NSMutableString because Python 
strings are always immutable -- correct?

--

ObjC -> Python

A more difficult case because there isn't [yet] a <string> base type to 
inherit from that is used for all 'are you a string' testing.

However, if one were to implement a Python module that providing a 
<character buffer> type API that wraps around an NSString [immutable 
only] instance, it appears that most of the Python core would handle 
that particular argument just fine.

Example:   the open() or file() functions would work just fine as long 
as the inbound object for the <name> argument is a character buffer (as 
that function-- open is just an alias for file anyway-- uses 'et' as 
the parse format for PyArgs_ParseTupleAndKeywords()).

--

Furthermore, the (id) of an object-- the address contained in self-- is 
often used as a meaningful identifier.   If a developer places an 
object into a container-- a dictionary or an array-- they expect to 
retrieve the exact same instance-- the same self pointer-- upon 
retrieving that object.

In this context, that an object is an (int) and the first 100 ints are 
singletons is completely irrelevant.   Consider the object in pure OO 
terms-- it is just an object contained in a collection, its type does 
not matter.

In my experience with bridging-- many years and going between a number 
of different languages-- conversion always turns out to be a headache.  
  Sometimes, there is more benefit from doing the conversion than there 
would be from not doing so,  but that is *rarely* the case and there is 
*always* a price to be paid for doing the conversion.

Do not discount the performance hit -- it can be truly nasty.   In the 
context of the Java<->ObjC bridge, the fact that Strings<->NSStrings 
conversions occur means that bridged code using ObjC collections is so 
astoundingly slow and memory inefficient as to require the developer to 
often change the design patterns radically (at least, that *was* the 
case with the WO 4.5 / OS X PB and prior bridge -- don't know if it 
still is, but I imagine it likely is).   In the case of Java, doing 
this kind of conversion is basically a requirement in that you can't 
subclass Java's String class and the kit of objects has no analogous 
structure such as Python's use of <character buffer>.

b.bum

On Monday, Feb 3, 2003, at 11:45 US/Eastern, Just van Rossum wrote:
> [Bob Ippolito]
>>> It's what I call a "real pain in the ass", at least when
>>> NSMutableString gets bridged into a PyString.
>
> Now _that's_ a bug. There is no Python equivalent to NSMutableString, 
> so
> it makes no sense to convert it.
>
> [Ronald Oussoren]
>> A real argument for not doing the conversion!
>
> Nope, an argument for not converting NSMutableString ;-)

Re: [Pyobjc-dev] Auto bridging instances by conversion

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

[Bob Ippolito]
> > It's what I call a "real pain in the ass", at least when 
> > NSMutableString gets bridged into a PyString.

Now _that's_ a bug. There is no Python equivalent to NSMutableString, so
it makes no sense to convert it.

[Ronald Oussoren]
> A real argument for not doing the conversion!

Nope, an argument for not converting NSMutableString ;-)

Just

Re: [Pyobjc-dev] More on integer values

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

On Monday, Feb 3, 2003, at 10:59 US/Eastern, David Eppstein wrote:
> I can write a test, but first I have to know what I am testing for.
> Is it a bug that undoManager converts int to Cocoa integer?
> That Cocoa integers remain unconverted when sent back to the Python 
> side?
> Or that I can't send a Cocoa integer to a method that expects an int?

If you aren't sure, don't worry about it....

Just write a test that demonstrates the problem that you are 
experiencing.   The development team can figure out what the bug is and 
break up the test for clarification, if necessary, or fix the problem 
directly.

Some testing is better than no testing at all, even if the test is not 
of the same granularity as the underlying code/problem/feature it is 
testing.

b.bum

Re: [Pyobjc-dev] Auto bridging instances by conversion

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

On Monday, Feb 3, 2003, at 16:58 Europe/Amsterdam, Bob Ippolito wrote:

>
> On Monday, Feb 3, 2003, at 10:30 America/New_York, Just van Rossum 
> wrote:
>
>> bb...@ma... wrote:
>>
>>> The fact that NSString<->PyString are converted is a bug --
>>
>> To me it isn't, it's what I call "transparent". This feature is
>> absolutely a _pleasure_ to work with.
>
> It's what I call a "real pain in the ass", at least when 
> NSMutableString gets bridged into a PyString.
A real argument for not doing the conversion!

Not converting can also be problematic: What if you pass the NSString 
to an extension-function that expects a string (like open), unless 
these get changed to also accept NSStrings you'll have to perform 
manual conversion from NSString to a python string.

>
> Why can't we wrap the NSString class cluster with some cruft that 
> makes it pythonic instead of converting it to something that it 
> wasn't?  There is absolutely no namespace clash between NSString and 
> PyString, with the added bonus that NSString can do just about 
> everything that PyString can with one line of code or less.

The 'problem' with NSString is that its interface is much more 
powerfull than that of python strings (the word cruft springs to mind 
when seeing methods like stringByAbbreviatingWithTildeInPath).

In case anyone cares: I (still) haven't made made my mind up on whether 
automaticly converting values is a usefull feature or not. There are to 
many irritating 'features' on either solution (converting or wrapping).

Ronald

[Pyobjc-dev] Request for Tests

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

Folks--

     We are now entering into a stage in development where the 
foundation has solidified, but there are questions regarding exactly 
how the structure on that foundation will evolve.   Namely, we are 
faced with decisions regarding memory managing, conversions across the 
bridge, and other complexities.

     Some of these issues are resulting in behavior within the current 
code that may be construed as a bug or is simply sub-optimal.

     If you have found a particular situation where the bridge is 
behaving badly-- badly defined by bug or personal opinion-- it would be 
extremely helpful if you could produce a test case that demonstrates 
the erroneous behavior.

     A demonstration of the behavior as a TestCase would be ideal and 
there are quite a number of test cases in Lib/*/test that can be copied 
to provide the basis for your test.   As many of you may not be 
familiar with pyunit based testing, a short script demonstrating the 
problem will work almost as well.

     I will make sure to commit any submitted test cases into the CVS 
repository, as appropriate.   The more test cases the better...

     There is precedent indicating how effective this is -- David [I got 
the name right, right? I'm very bad about that] submitted a short 
script demonstrating a handful of problems with the bridge and it was 
fixed in short order.

     b.bum

Re: [Pyobjc-dev] More on integer values

[David E. <epp...@ic...>]

On 2/3/03 9:02 AM -0500 bb...@ma... wrote:
> We need unit tests.  David:   do you have a test case that demonstrates
> the mishandling of integers with NSUndoManager?
>
> If you could send it to me, I will integrate it into the
> test_nsundomanager.py in Lib/Foundation/test/.

I can write a test, but first I have to know what I am testing for.
Is it a bug that undoManager converts int to Cocoa integer?
That Cocoa integers remain unconverted when sent back to the Python side?
Or that I can't send a Cocoa integer to a method that expects an int?

My feeling is that the first two are ok and the third is a problem, but I'm 
not seeing a concensus on this.
--
David Eppstein       UC Irvine Dept. of Information & Computer Science
epp...@ic... http://www.ics.uci.edu/~eppstein/

Re: [Pyobjc-dev] Auto bridging instances by conversion

[Bob I. <bo...@re...>]

On Monday, Feb 3, 2003, at 10:30 America/New_York, Just van Rossum 
wrote:

> bb...@ma... wrote:
>
>> The fact that NSString<->PyString are converted is a bug --
>
> To me it isn't, it's what I call "transparent". This feature is
> absolutely a _pleasure_ to work with.

It's what I call a "real pain in the ass", at least when 
NSMutableString gets bridged into a PyString.

Why can't we wrap the NSString class cluster with some cruft that makes 
it pythonic instead of converting it to something that it wasn't?  
There is absolutely no namespace clash between NSString and PyString, 
with the added bonus that NSString can do just about everything that 
PyString can with one line of code or less.

-bob

Re: [Pyobjc-dev] More on integer values

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

On Monday, Feb 3, 2003, at 15:02 Europe/Amsterdam, bb...@ma... wrote:

> We need unit tests.  David:   do you have a test case that 
> demonstrates the mishandling of integers with NSUndoManager?
>
> If you could send it to me, I will integrate it into the 
> test_nsundomanager.py in Lib/Foundation/test/.
>
> A unit test demonstrating the problem will ensure that we are all 
> talking about the problem using the same vocabulary and expectations.
>
> On Monday, Feb 3, 2003, at 02:13 US/Eastern, Ronald Oussoren wrote:
>> Not too hard. There are (at least) two possible solutions:
>>
>> - David could use objc.selector to specify a signature that is more 
>> to its liking (e.g. one of the
>>   arguments is an int instead of an object). I don't really like 
>> this, mostly because of the arcane
>>   interface of selector()
>
> Wouldn't this require applying the objc.selector() to the undo 
> manager?   That seems problematic for a number of reasons.   Of 
> course, if David were to subclass NSUndoManager and apply the 
> objc.selector() calls to that subclass, it wouldn't be a problem.
>
> I.e.:
>
> class FundoManager(NSUndoManager):
>     setColorCount_ = objc.selector(None, selector="setColorCount:", 
> signature="v@:i")
>

It wouldn't be necessary, from what I understand the NSUndoManager will 
forward calls to methodSignatureForSelector: to the current target, 
e.g. you have to use the call to selector in the class that defines 
'setColurCount:'.

> If that is the case, it is a bummer, but not altogether too ugly save 
> for the 'signature' argument.   If we were to declare a handful of our 
> own types, the signature could be defined as an array of type objects. 
>  Something like:
>
>     signature = [VoidType, IDType, SelectorType, IntType]
>
> Actually, it really should be two different arguments to selector():
>
>     objc.selector(None, selector="setColorCount:", 
> returnType=VoidType, argumentTypes=[IntType])
>
> We can drop the IDType and SelectorType specs because every selector 
> must take (id) and (SEL) as the first two arguments.

You can already use a variation on this theme: use 'return_type' and 
'argument_types'. Both are specified using a subset of the 
Py_BuildValue syntax, argument_types should not describe self and _cmd.

I prefer this to your proposal because Py_BuildValue will be familiar 
to at least some python programmers.

BTW. We do have documentation for this (-:

 >>> import objc
 >>> help(objc.selector)
Help on class selector in module objc:

class selector(__builtin__.object)
  |  selector(function, [, signature] [, selector] [, class_method=0]
  |      [, return_type] [, argument_types] [, required=True]) -> 
selector
  |
  |  Return an Objective-C method from a function. The other arguments
  |  specify attributes of the Objective-C method.
  |
  |  function:
  |    A function object with at least one argument. The first argument 
will
  |    be used to pass 'self'. This argument may be non when defineing an
  |    informal_protocol object.
  |  selector:
  |    The name of the Objective-C method. The default value of this
  |    attribute is the name of the function, with all underscores 
replaced
  |    by colons.
  |  signature:
  |    Method signature for the Objective-C method. This should be a raw
  |    Objective-C method signature, including specifications for 'self' 
and
  |    '_cmd'. The default value a signature that describes a method with
  |    arguments of type 'id' and a return-value of the same type.
  |  argument_types, return_type:
  |    Alternative method for specifying the method signature. 
Return_type is
  |    return type and argument_types describes the list of arguments. 
The
  |    return_type is optional and defaults to 'void' (e.g. no return 
value).
  |    Both are specified using a subset of the Py_BuildValue syntax:
  |    - s, z, S: an NSString (id)
  |    - b: a byte (char)
  |    - h: a short integer (short int)
  |    - i: an integer (int)
  |    - l: a long integer (long int)
  |    - c: a single character (char)
  |    - f: a single precision float (float)
  |    - d: a double precision float (double)
  |    - O: any object (id)
  |    It is not allowed to specify both 'argument_types' and 'signature'
  |  class_method:
  |    True if the method is a class method, false otherwiserequired:
  |    True if this is a required method in an informal protocol, false
  |    otherwise. The default value is 'True'. This argument is only used
  |    when defining an 'informal_protocol' object.
  |

>
>> - We could treat NSNumber like a Python number when translating 
>> arguments to Objective-C values. Doing
>>   that would not be too hard. Or we could translate NSNumbers to 
>> Python numbers when translating from
>>   Objective-C values to Python values, but I don't think we should do 
>> that.
>
> [For the following, the exact same discussion could be applied to 
> floats/doubles]
>
> There are two distinct problems associated with handling integer types 
> as a result of their being three different means of encapsulating an 
> integer within a PyObjC based application.   There is the native C 
> (int) type, a Python IntType, and NSValue/NSNumber instances.
>
> The first problem is associated with converting (int) to Python 
> IntTypes and back.   This generally works fine in the current code 
> base.  Where it falls apart is in cases like the one David is 
> describing with NSUndoManager.  That is, when a method that takes an 
> integer argument is invoked through the bridge against a proxy object 
> that does not contain the signature of the method to be invoked.

That is not a problem with the bridge, but in the way it is used: The 
bridge cannot know that the user expects an int/float instead of an 
object unless it is told so.

>
> If the aforementioned potential fix doesn't work, I'm not sure what 
> will.
>
> The second problem involves the bridging of NSNumber into Python 
> numbers and vice versa.   Currently, this doesn't appear to be broken. 
>  It is also not an issue in the context of David's problem.   There 
> may be some subtleties that could be cleaned up in this context, 
> though.   As mentioned in the "autobridging by conversion" message, it 
> may be useful to create a custom subclass of NSValue that can 
> encapsulate the various Python number types.  This would allow us to 
> preserve the python instance when a number comes back across the 
> bridge.  Not only does this increase transparency of the bridge, but 
> it may also reduce memory footprint and increase performance [in that 
> we would just recycle the python instance coming back].

This *is* a problem in the context of David's problem. He is passing an 
object ("coincidently" an Python int) through the Objective-C runtime 
from Python to Python. In the process this object is translated into a 
completely different object.

We could automaticly translate NSNumber objects to Python numbers, that 
would solve most, if not all, problems with passing numbers 'through' 
Objective-C. However, this is not entirely trivial: You must take care 
to extract the right kind of basic type from the NSNumber otherwise 
you'd loose information.

BTW. If we do this some of the unit tests will fail (those that abuse 
NSArray to create NSNumber objects). Hmm, that is not really a problem: 
NSNumber objects would completely disappear from user code.

Ronald

Re: [Pyobjc-dev] Auto bridging instances by conversion

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

bb...@ma... wrote:

> If the goal is to make the bridge as transparent as possible,
> automatically converting instances-- and losing the original
> instance-- as they pass across the bridge should be eliminated.

If this is a refcount problem I can see that, but other than that, since
Python numbers and NSNumber instances are immutable I don't see why it
would ever matter to get a different instance. Wg. in Python it is an
implementation detail that ints between -1 and 99 (as well as the empty
tuple, empty string, strings of length 1) are singletons: one should
never rely on that.

To me, making "the bridge as transparent as possible" means the exact
opposite: native Python objects on the Python side (strings, ints,
floats, etc) and using native Cocoa objects on the ObjC side. I don't
care about the performance hit, and I'm not even sure passing numbers
back and forth over the bridge is such a common thing (but I'm sure you
can prove otherwise ;-).

> The fact that NSString<->PyString are converted is a bug --

To me it isn't, it's what I call "transparent". This feature is
absolutely a _pleasure_ to work with.

> certainly, a bug we have chosen to live with until a better solution
> comes along. Mostly, we can get away with this because two strings
> with the same contents act like the same string.

Yeah, that's a neat property of them being immutable. I would figure the
same goes for NSNumber, so apart from performance I don't see anything
against converting back and forth.

> For Python strings -> Objective-C, it is simply a matter of creating
> a subclass of the NSString class cluster in the same fashion as we do
> for NSArray and NSDictionary.    For NSString -> Python StringType,
> it isn't clear that there is a set of methods or a base type to
> inherit from that can make an NSString behave like a python string
> transparently enough to make it a worthwhile pursuit at this point in
> time.

It is clear: there is no such base class. In 2.3 there is an abstract
base class called basestring but that doesn't implement anything.

Just

Re: [Pyobjc-dev] More on integer values

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

We need unit tests.  David:   do you have a test case that demonstrates 
the mishandling of integers with NSUndoManager?

If you could send it to me, I will integrate it into the 
test_nsundomanager.py in Lib/Foundation/test/.

A unit test demonstrating the problem will ensure that we are all 
talking about the problem using the same vocabulary and expectations.

On Monday, Feb 3, 2003, at 02:13 US/Eastern, Ronald Oussoren wrote:
> Not too hard. There are (at least) two possible solutions:
>
> - David could use objc.selector to specify a signature that is more to 
> its liking (e.g. one of the
>   arguments is an int instead of an object). I don't really like this, 
> mostly because of the arcane
>   interface of selector()

Wouldn't this require applying the objc.selector() to the undo manager? 
   That seems problematic for a number of reasons.   Of course, if David 
were to subclass NSUndoManager and apply the objc.selector() calls to 
that subclass, it wouldn't be a problem.

I.e.:

class FundoManager(NSUndoManager):
     setColorCount_ = objc.selector(None, selector="setColorCount:", 
signature="v@:i")

If that is the case, it is a bummer, but not altogether too ugly save 
for the 'signature' argument.   If we were to declare a handful of our 
own types, the signature could be defined as an array of type objects.  
Something like:

     signature = [VoidType, IDType, SelectorType, IntType]

Actually, it really should be two different arguments to selector():

     objc.selector(None, selector="setColorCount:", returnType=VoidType, 
argumentTypes=[IntType])

We can drop the IDType and SelectorType specs because every selector 
must take (id) and (SEL) as the first two arguments.

> - We could treat NSNumber like a Python number when translating 
> arguments to Objective-C values. Doing
>   that would not be too hard. Or we could translate NSNumbers to 
> Python numbers when translating from
>   Objective-C values to Python values, but I don't think we should do 
> that.

[For the following, the exact same discussion could be applied to 
floats/doubles]

There are two distinct problems associated with handling integer types 
as a result of their being three different means of encapsulating an 
integer within a PyObjC based application.   There is the native C 
(int) type, a Python IntType, and NSValue/NSNumber instances.

The first problem is associated with converting (int) to Python 
IntTypes and back.   This generally works fine in the current code 
base.  Where it falls apart is in cases like the one David is 
describing with NSUndoManager.  That is, when a method that takes an 
integer argument is invoked through the bridge against a proxy object 
that does not contain the signature of the method to be invoked.

If the aforementioned potential fix doesn't work, I'm not sure what 
will.

The second problem involves the bridging of NSNumber into Python 
numbers and vice versa.   Currently, this doesn't appear to be broken.  
It is also not an issue in the context of David's problem.   There may 
be some subtleties that could be cleaned up in this context, though.   
As mentioned in the "autobridging by conversion" message, it may be 
useful to create a custom subclass of NSValue that can encapsulate the 
various Python number types.  This would allow us to preserve the 
python instance when a number comes back across the bridge.  Not only 
does this increase transparency of the bridge, but it may also reduce 
memory footprint and increase performance [in that we would just 
recycle the python instance coming back].

b.bum

Re: [Pyobjc-dev] NSBeginAlertSheet support

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

On Sunday, Feb 2, 2003, at 12:17 US/Eastern, Etienne Posthumus wrote:
> Working my way through the Learning Cocoa book, but doing the examples 
> in Python in stead of Objective-C.
> 'Dotview' worked fine, but in trying to add an alert sheet I can't 
> import NSBeginAlertSheet from AppKit.
> I get a 0 on 'NSBeginAlertSheet' in dir(AppKit), but according to the 
> docs it is a function in AppKit.
>
> Where do I begin looking for what functions get bridged, and how to 
> confirm if it is truly missing or just me barking up the wrong tree?

They are not currently bridged due to what appears to be a bug in the 
func_builder.py script used to auto-bridge the various functions.  
Specifically:

Converting 'APPKIT_EXTERN void NSBeginAlertSheet(NSString *title, 
NSString *defaultButton, NSString *alternateButton, NSString 
*otherButton, NSWindow *docWindow, id modalDelegate, SEL 
didEndSelector, SEL didDismissSelector, void *contextInfo, NSString 
*msg, ...);' ...failed: Complex function (retval)
Converting 'APPKIT_EXTERN void NSBeginInformationalAlertSheet(NSString 
*title, NSString *defaultButton, NSString *alternateButton, NSString 
*otherButton, NSWindow *docWindow, id modalDelegate, SEL 
didEndSelector, SEL didDismissSelector, void *contextInfo, NSString 
*msg, ...);' ...failed: Complex function (retval)
Converting 'APPKIT_EXTERN void NSBeginCriticalAlertSheet(NSString 
*title, NSString *defaultButton, NSString *alternateButton, NSString 
*otherButton, NSWindow *docWindow, id modalDelegate, SEL 
didEndSelector, SEL didDismissSelector, void *contextInfo, NSString 
*msg, ...);' ...failed: Complex function (retval)

It appears that func_builder.py is not correctly identifying these 
functions-- and quite a few others-- as returning a simple [integer or 
void] return type.

b.bum

Re: [Pyobjc-dev] applicationShouldOpenUntitledFile_

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

On Monday, Feb 3, 2003, at 02:18 US/Eastern, Ronald Oussoren wrote:
> Argh, I think I'm going mad... Did anyone else try this? One other 
> thing that may make a difference: I've build my python 2.3 (framework 
> install) with 'OPT=-O3 -mcpu=604 -faltivec -prebind -g'.

Much better now.

The problem has gone away on my system;   the delegate method does the 
right thing for both FFI and non-FFI builds of pyobjc.   I have also 
made the API mismatch messages go away.

Part of the problem on my system was that I had screwed up the 
Document-based project template such that it always copied PyObjC into 
the Resources directory of the .app target.   This would cause PyObjC 
to always load the module from the app wrapper and the version 
gradually fell behind that which came from PyObjC CVS.

I apologize for the confusion.

b.bum

[Pyobjc-dev] Auto bridging instances by conversion

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

On Monday, Feb 3, 2003, at 03:05 US/Eastern, Just van Rossum wrote:
>> Or we could translate NSNumbers to Python numbers when translating
>> from Objective-C values to Python values, but I don't think we should
>> do that.
> Why not? It would surely be the least surprising behavior?

See my other message regarding David's problem.

This would not solve the problem that David is having.  Automatically 
converting NSNumbers to Python numbers and vice-versa is unnecessary 
and would lead to a major performance hit-- both CPU and memory-- in 
any many applications.

In general, we do not want to autoconvert objects passing across the 
bridge unless it is unavoidable.   Beyond the memory and CPU 
implications, it'll really hose any code that relies on the instance to 
the stay the same when passing across the bridge.

If the goal is to make the bridge as transparent as possible, 
automatically converting instances-- and losing the original instance-- 
as they pass across the bridge should be eliminated.

The fact that NSString<->PyString are converted is a bug -- certainly, 
a bug we have chosen to live with until a better solution comes along.  
  Mostly, we can get away with this because two strings with the same 
contents act like the same string.

For Python strings -> Objective-C, it is simply a matter of creating a 
subclass of the NSString class cluster in the same fashion as we do for 
NSArray and NSDictionary.    For NSString -> Python StringType, it 
isn't clear that there is a set of methods or a base type to inherit 
from that can make an NSString behave like a python string 
transparently enough to make it a worthwhile pursuit at this point in 
time.

Actually, for NSNumber there isn't any particular reason why a Python 
number type could not be encapsulated in an instance of a subclass of 
NSValue.   It really doesn't buy us much since both sides of the bridge 
do a pretty good job of treating the instance of IntType or NSNumber 
that encapsulates a particular number as identical to another instance 
of the same class encapsulating the same number.

b.bum

Re: [Pyobjc-dev] IB question

[Michael E. <men...@ka...>]

No I was just adding it it MyAppDelegate.py  - when I added it to 
another python class in another file using the 
Cocoa-Document-Application template that seemed to work.   Still all 
last night I played with it just with something as simple as the 
example I gave  and it worked on and off between cleaning and building.
I'm going to order the December developer tools today and see if that 
fixes things.

Thanks for the help.

Mike
On Monday, February 3, 2003, at 04:37  AM, Etienne Posthumus wrote:

> You mention that you added sayGoodbyeAction: to the class and 
> instantiated it - but to which class did you add it? If you are just 
> adding an extra button to the example, you shouldn't have to 
> instantiate anything. You only need to add the new action to the 
> MyAppDelegate, and then add the method to the Python code in 
> MyAppDelegate.py.    Are you trying to add a whole new custom class? 
> If so, that has to go in a separate Python class.
>
> EP
>