pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] Re: pdb in PyObjC apps?

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

On Tuesday, Aug 19, 2003, at 05:45 America/New_York, Michael Hudson 
wrote:

> Zachery Bir <zb...@ur...> writes:
>
>> Note to self: Don't use pdb and try to catch it through
>> double-clicking  the app :)
>
> :-)
>
> It shouldn't be *too* outrageously hard to teach my pyrepl interactive
> tool how to cooperate with the Cocoa run loop (you need a way to give
> an fd to Cocoa and say "give me control when there's something to read
> on this" and I'm sure I saw one of them somewhere) in which case you
> could have an interactive session running alongside your
> application... Hmm, where's that can of tuits?

I've developed a CoreFoundation reactor for Twisted that would 
facilitate this sort of thing.  It's not mainline yet because I haven't 
had time to fully test and write enough examples -- it does work, but 
I'm not currently comfortable putting it in the rest of Twisted yet 
(especially due to the Pyrex build dependency).

Here's what you would do (this obviously needs Developer Tools 
installed):

Download Pyrex 0.8.2

Modify Pyrex/Compiler/Nodes.py .. change the block starting on line 160 
to this (small fix to allow system includes):
     for filename in env.include_files:
       if not (filename.startswith('<') and filename.endswith('>')):
         filename = '"%s"' % filename
       code.putln('#include %s' % filename)

Install Pyrex

Checkout CVS HEAD of Twisted

Build and install Twisted (or put twisted into your PYTHONPATH, I have 
a symlink of ~/src/Twisted/twisted at 
~/Library/Python/2.3/site-packages/twisted)

Go into Twisted/sandbox/etrepum/cfsupport

python setup.py build_ext -i

cd TWISTEDPACKAGE/internet
ln -s TWISTEDCVS/sandbox/etrepum/cfreactor.py .
ln -s TWISTEDCVS/sandbox/etrepum/cfsupport/cfsupport.so .

That should work, to test it check out the examples in 
TWISTEDCVS/sandbox/etrepum/examples/PyObjC (which obviously require 
PyObjC, you can get that from PackageManager)

Also note that the cfsupport module is enough to just get notifications 
on the fd, but I recommend using Twisted for anything that talks 
sockets anyway.

-bob

[Pyobjc-dev] Re: pdb in PyObjC apps?

[Michael H. <mw...@py...>]

Zachery Bir <zb...@ur...> writes:

> Note to self: Don't use pdb and try to catch it through
> double-clicking  the app :)

:-)

It shouldn't be *too* outrageously hard to teach my pyrepl interactive
tool how to cooperate with the Cocoa run loop (you need a way to give
an fd to Cocoa and say "give me control when there's something to read
on this" and I'm sure I saw one of them somewhere) in which case you
could have an interactive session running alongside your
application... Hmm, where's that can of tuits?

Cheers,
mwh

-- 
  same software, different verbosity settings (this one goes to
  eleven)                             -- the effbot on the martellibot

Re: [Pyobjc-dev] pdb in PyObjC apps?

[Zachery B. <zb...@ur...>]

On Monday, August 18, 2003, at 05:56 PM, Bob Ippolito wrote:

> On Monday, Aug 18, 2003, at 16:49 America/New_York, Zachery Bir wrote:
>
>> Anyone found a way to integrate the python debugger (pdb) with a  
>> PyObjC application? I made the mistake of trying it, and it clogged  
>> up my Console.app and I had to use Force Quit to stop my app.
>
> You can probably use it pretty much the same way you would normally  
> use pdb.  There's probably a couple snags (NSApplicationMain will  
> probably kill the interpreter when the runloop stops,  
> AppHelper.runEventLoop will probably try and catch all your  
> exceptions, etc.), but you didn't really give enough information about  
> your problem.  You should be more concise about exactly what you did,  
> especially how it was executed (WindowServer is picky about these  
> things).  You should also include some sample code (preferably  
> stripped down to just enough to show the problem), and define what  
> "clogged up my Console.app" means.

Sorry, something along the lines of:

class MyAppDelegate(NibClassBuilder.AutoBaseClass):

   def init(self):

     import pdb;pdb.set_trace()
     self.foo = do_something()

So that I can track the creation of my application's main object and  
see where this disconnect that I'm experiencing is coming from.

When I tried that before and ran the built application by  
double-clicking on it, Console.app was filled with:

(Pdb) (Pdb) (Pdb) (Pdb) (Pdb) (Pdb) (Pdb) (Pdb) (Pdb) (Pdb) (Pdb) (Pdb)  
(Pdb) (Pdb) (Pdb) (Pdb) (Pdb) (Pdb) (Pdb) (Pdb) (Pdb) (Pdb) (Pdb) (Pdb)  
(Pdb) (Pdb) (Pdb) (Pdb) (Pdb) (Pdb) (Pdb) ...

   ad nauseum when that line was hit. There was no terminal I could  
attach to to take charge of the pdb session. Perhaps I need to run the  
application differently? (trying that) AHA!

Running:

   $  
~/Developer/ZopeEditManager/build/ZopeEditManager.app/Contents/MacOS/ 
ZopeEditManager

with the import pdb;pdb.set_trace() in my app's init() method brings me  
to a pdb prompt :)

Note to self: Don't use pdb and try to catch it through double-clicking  
the app :)

>> Should we be using the Project Builder's debugger? Will that work?
>
> Not unless you're debugging Python itself, or an extension written in  
> C, C++, Objective C :)  Project Builder's debugger is just a gdb  
> frontend.

Good to know, thanks.

Zac

Re: [Pyobjc-dev] pdb in PyObjC apps?

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

On Monday, Aug 18, 2003, at 16:49 America/New_York, Zachery Bir wrote:

> Anyone found a way to integrate the python debugger (pdb) with a 
> PyObjC application? I made the mistake of trying it, and it clogged up 
> my Console.app and I had to use Force Quit to stop my app.

You can probably use it pretty much the same way you would normally use 
pdb.  There's probably a couple snags (NSApplicationMain will probably 
kill the interpreter when the runloop stops, AppHelper.runEventLoop 
will probably try and catch all your exceptions, etc.), but you didn't 
really give enough information about your problem.  You should be more 
concise about exactly what you did, especially how it was executed 
(WindowServer is picky about these things).  You should also include 
some sample code (preferably stripped down to just enough to show the 
problem), and define what "clogged up my Console.app" means.

> Should we be using the Project Builder's debugger? Will that work?

Not unless you're debugging Python itself, or an extension written in 
C, C++, Objective C :)  Project Builder's debugger is just a gdb 
frontend.

-bob

[Pyobjc-dev] pdb in PyObjC apps?

[Zachery B. <zb...@ur...>]

Anyone found a way to integrate the python debugger (pdb) with a PyObjC 
application? I made the mistake of trying it, and it clogged up my 
Console.app and I had to use Force Quit to stop my app.

Should we be using the Project Builder's debugger? Will that work?

Thanks,

Zac

[Pyobjc-dev] Application lost its mind...

[Zachery B. <zb...@ur...>]

Hey, all.

It seems I introduced a new variable to my app, when I unblocked myself 
working with NSTimers.

At the same time I figured it out, I also heavily refactored my 
application and so now, have lost major functionality.

The current incarnation is attached. Before this, the python class 
ZopeDocument and most of the code in its __init__() were in the 
ZopeEditController's application_openFile_() method. Since refactoring 
the class out, application_openFile_() never gets called. I suspect 
that it might be the concurrent addition of the NSTimer object to sweep 
the various files in play in ZopeEditController's init() method.

Any thoughts?

Zac

[Pyobjc-dev] re: SIGSEGVs

[Sean G. <se...@bl...>]

Hello all,

	I have a project that has a few NSTableDataSource subclasses, and an 
NSOutlineViewDataSource, which is in an NSDrawer.  I assign attributes 
to each of these views, some of which refer to each other, and their 
respective Views.  Most of the time, I am getting SIGSEGVs.  Sometimes, 
everything works fine, and I am able to get through a test session with 
my program.  If I take all the View and DataSource code out, it all 
seems to work fine.  Have any of you heard of something like this?  
Here is how I define my DataSources:

class ProfileViewDataSource( NSObject, NSOutlineViewDataSource ):

class DownloadViewDataSource( NSObject, NSTableDataSource, 
Job.JobListener, Job.JobSchedulerListener ):

class DLQueueViewDataSource( NSObject, NSTableDataSource ):

Here is the standard init( ) that I am using for these classes:

     def init( self ):
         self = super( ProfileViewDataSource, self ).init( )

	#init code..

         return self

Thank you for your time,
	Sean

[Pyobjc-dev] [ pyobjc-Bugs-789209 ] NSBezierPath.getLineDash_count_phase_

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

Bugs item #789209, was opened at 2003-08-15 14:27
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=789209&group_id=14534

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martina Oefelein (oefe)
Assigned to: Nobody/Anonymous (nobody)
Summary: NSBezierPath.getLineDash_count_phase_

Initial Comment:
>>> from AppKit import *
>>> bp = NSBezierPath.bezierPath()
>>> bp.setLineDash_count_phase_((1, 2.5, 0.5, 0.5), 4, 0)
>>> bp.getLineDash_count_phase_()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: Cannot call getLineDash:count:phase: on 
<NSBezierPath objective-c instance 0x6b9fb0> from Python

For this example, I would expect it to return ((1, 2.5, 0.5, 
0.5), 4, 0)

In both setLineDash_count_phase_ and 
getLineDash_count_phase_, the count parameter is 
redundant with the size of the tuple. It would be better to 
omit this parameter:
>>> bp.setLineDash_count_phase_((1, 2.5, 0.5, 0.5), 0)
>>> bp.getLineDash_count_phase_()
((1, 2.5, 0.5, 0.5), 0)

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

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

[Pyobjc-dev] [ pyobjc-Bugs-789193 ] NSFileManager.stringWithFileSystemRepresentation_length_

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

Bugs item #789193, was opened at 2003-08-15 13:48
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=789193&group_id=14534

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martina Oefelein (oefe)
Assigned to: Nobody/Anonymous (nobody)
Summary: NSFileManager.stringWithFileSystemRepresentation_length_

Initial Comment:
>>> from Foundation import *
>>> fm = NSFileManager.defaultManager()
>>> fm.stringWithFileSystemRepresentation_length_("/var")
Bus error


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

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

[Pyobjc-dev] [ pyobjc-Bugs-789205 ] NSBitmapImageRep.getTIFFCompressionTypes_count_

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

Bugs item #789205, was opened at 2003-08-15 14:17
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=789205&group_id=14534

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martina Oefelein (oefe)
Assigned to: Nobody/Anonymous (nobody)
Summary: NSBitmapImageRep.getTIFFCompressionTypes_count_

Initial Comment:
>>> from AppKit import *
>>> 
NSBitmapImageRep.getTIFFCompressionTypes_count_()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: Need 2 arguments, got 0

OK, so I try:
>>> types = [1,2,3,4]
>>> 
NSBitmapImageRep.getTIFFCompressionTypes_count_(types, 
4)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: depythonifying 'pointer', got 'list'

I would expect that this function, when called from Python, 
takes no arguments and returns a single tuple of TIFF 
compression types. (No need to return 'count' explicitly. It is 
implied by the size of the tuple.)



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

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

Re: [Pyobjc-dev] Recent change to K/V coding

[Pierce T. W. I. <pi...@tw...>]

On Thursday, August 14, 2003, at 01:19 PM, Ronald Oussoren wrote:

>
> On Thursday, 14 August, 2003, at 21:49, b.bum wrote:
>
>> The only change I made was the addition of KeyValueCodingMixIn -- a 
>> class in KeyValueCoding that can be mixed into any pure python class 
>> to add valueForKey_(), takeValue_forKeyPath_(), etc...    Useful, but 
>> easy to duplicate, certainly.
>
> Why is this useful? If you want to feed the object to an Objective-C 
> class/method that will use KVC to set/get attributes, the 
> implementation of OC_PythonObject (which is used to wrap Python 
> objects when accessed from Objective-C) already contains a full 
> implementation of KVC.
>
> If you want use KVC from Python you can use the functions in 
> PyObjCTools.KeyValueCoding or subclass from NSObject. In either case 
> you don't need the mixin. And as I wrote earlier, the methods in the 
> mixin will *never* be called from Objective-C, which might confuse 
> users.

   As a long time user of KVC, I can tell you that its useful apart from 
ObjC. That's why the mix in is good. We should propose it as an 
addition to Python separate from PyObjC in fact.

>
>>
>> The one change I would like to see-- that I feel is very important-- 
>> is to fix the callable behavior such that it is inline with 
>> Objective-C.   The end result should be interchangeable with the 
>> Objective-C implementation.
>
> The current implementation tries to conform to the description of the 
> default behaviour of the KeyValueCoding protocol. There may be minor 
> differences due to me not understanding the documentation.

   I think you're just misunderstanding how its applied. KVC's power is 
that with runtime-bound languages (like Python), you can make arbitrary 
parameterless method calls from non-code files like say, user interface 
editing tools.

   Right now,

    object.key

    is interpreted as object.key instead of object.key(). That's the 
worst possible choice, because you want to be able to do

    string.title

    in a KVC binding to get string.title().

  Once you realize that, then the issue becomes whether you want to be 
able to do:

    class.instanceVar

  To pull instanceVar out of a class directly when it has no accessors.

  In that case, it would be confusing if it didn't work, since that 
looks too much like plain python. And in fact, the differences between 
objC and Python don't really matter, because python enforces the rule 
correctly on its side. That is, if someone asks for "a" using KVC you 
can pretty safely assume they really do want a(), because there is no 
self.a.

   The only gotcha would be in the case where you have an instance 
variable that also happens to be callable, but its not a method. I 
think that's kind of an obscure case, but perhaps we could check to see 
if its a bound method of the class?


  Pierce

Re: [Pyobjc-dev] Recent change to K/V coding

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

On Thursday, 14 August, 2003, at 22:58, Pierce T. Wetter III wrote:

>
> On Thursday, August 14, 2003, at 01:19 PM, Ronald Oussoren wrote:
>
>>
>> On Thursday, 14 August, 2003, at 21:49, b.bum wrote:
>>
>>> The only change I made was the addition of KeyValueCodingMixIn -- a 
>>> class in KeyValueCoding that can be mixed into any pure python class 
>>> to add valueForKey_(), takeValue_forKeyPath_(), etc...    Useful, 
>>> but easy to duplicate, certainly.
>>
>> Why is this useful? If you want to feed the object to an Objective-C 
>> class/method that will use KVC to set/get attributes, the 
>> implementation of OC_PythonObject (which is used to wrap Python 
>> objects when accessed from Objective-C) already contains a full 
>> implementation of KVC.
>>
>> If you want use KVC from Python you can use the functions in 
>> PyObjCTools.KeyValueCoding or subclass from NSObject. In either case 
>> you don't need the mixin. And as I wrote earlier, the methods in the 
>> mixin will *never* be called from Objective-C, which might confuse 
>> users.
>
>   As a long time user of KVC, I can tell you that its useful apart 
> from ObjC. That's why the mix in is good. We should propose it as an 
> addition to Python separate from PyObjC in fact.

There is little change methods like 'takeValue_forKey_' will be 
accepted into the Python core. The KeyValueCoding module has a larger 
change of being accepted. The only difference is the syntax you use to 
access attributes:

	setKey(object, "mykey", 3)

vs.

	object.takeValue_forKey_("mykey", 3)

The former works without a mix in class.

>
>>
>>>
>>> The one change I would like to see-- that I feel is very important-- 
>>> is to fix the callable behavior such that it is inline with 
>>> Objective-C.   The end result should be interchangeable with the 
>>> Objective-C implementation.
>>
>> The current implementation tries to conform to the description of the 
>> default behaviour of the KeyValueCoding protocol. There may be minor 
>> differences due to me not understanding the documentation.
>
>   I think you're just misunderstanding how its applied. KVC's power is 
> that with runtime-bound languages (like Python), you can make 
> arbitrary parameterless method calls from non-code files like say, 
> user interface editing tools.

Your previous message finally made me realize what you and bill are 
trying to say. Sorry for having such a thick scull.

I still think that we should only call instance methods using KVC, not 
the value of instance variables that happen to be callable. BTW. it 
might even be usefull to use __keyname__ as an accessor method for 
reading key keyname, this would make it possible to use KVC to get at 
the length of a string.

Ronald

Re: [Pyobjc-dev] Key/Value Coding

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

On Thursday, 14 August, 2003, at 22:40, Pierce T. Wetter III wrote:
>>>
>>
>> It may be trivial to get this to work, but not necessarily correct. 
>> In python the accessor methods are named 'get_value' and 'set_value' 
>> (or the camelcase variations of those), using accessors named like an 
>> attribute would be confusing.
>
>  Actually, I think you misunderstand the problem. KeyValueCoding as 
> checked in won't let you do:
>
>    object.accessor.accessor
>
>   because it needs to do:
>
>    object.accesssor().accessor() in python, and its assuming accessor 
> is a plain attribute, so it reutrns object.accessor the function 
> pointer. So you can walk chains of plain attributes, but you can't 
> walk any that have accessors involved, unless they have a "get" or 
> "get_" method. Since there's no "getLen()" or "getCapitalize()" on 
> string, or 99% of the methods of the other system classes, KVC has to 
> get the results of m=getattr, and if it is callable,
> return m().

<img src="lightbulb"> Aha, I, finally ;-), start to understand what the 
fuzz is all about. You want to be able to call normal argumentless 
methods using KVC. That might be usefull, I'll update the code to allow 
this.

Ronald

Re: [Pyobjc-dev] Key/Value Coding

[Pierce T. W. I. <pi...@tw...>]

On Thursday, August 14, 2003, at 12:58 PM, Ronald Oussoren wrote:

>
> On Thursday, 14 August, 2003, at 21:34, Pierce T. Wetter III wrote:
>>
>>> I'm going to roll back Bill's patch, it's not very usefull just 
>>> before a 1.0 release. I'm going to look at the unittest to check if 
>>> they add tests that should be added to the other KVC unittest files.
>>
>>  Actually, its a trivial change to get "key" to work as well. I sent 
>> changes independently to bill that fix most of the broken unit tests, 
>> except the ones where python is subclassing. In that case, the 
>> objects aren't getting built for some reason, so I'll have to pass on 
>> those.
>
> It may be trivial to get this to work, but not necessarily correct. In 
> python the accessor methods are named 'get_value' and 'set_value' (or 
> the camelcase variations of those), using accessors named like an 
> attribute would be confusing.

  Actually, I think you misunderstand the problem. KeyValueCoding as 
checked in won't let you do:

    object.accessor.accessor

   because it needs to do:

    object.accesssor().accessor() in python, and its assuming accessor 
is a plain attribute, so it reutrns object.accessor the function 
pointer. So you can walk chains of plain attributes, but you can't walk 
any that have accessors involved, unless they have a "get" or "get_" 
method. Since there's no "getLen()" or "getCapitalize()" on string, or 
99% of the methods of the other system classes, KVC has to get the 
results of m=getattr, and if it is callable, return m().

  
  

Re: [Pyobjc-dev] Recent change to K/V coding

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

On Thursday, 14 August, 2003, at 21:49, b.bum wrote:

> The only change I made was the addition of KeyValueCodingMixIn -- a 
> class in KeyValueCoding that can be mixed into any pure python class 
> to add valueForKey_(), takeValue_forKeyPath_(), etc...    Useful, but 
> easy to duplicate, certainly.

Why is this useful? If you want to feed the object to an Objective-C 
class/method that will use KVC to set/get attributes, the 
implementation of OC_PythonObject (which is used to wrap Python objects 
when accessed from Objective-C) already contains a full implementation 
of KVC.

If you want use KVC from Python you can use the functions in 
PyObjCTools.KeyValueCoding or subclass from NSObject. In either case 
you don't need the mixin. And as I wrote earlier, the methods in the 
mixin will *never* be called from Objective-C, which might confuse 
users.

>
> The one change I would like to see-- that I feel is very important-- 
> is to fix the callable behavior such that it is inline with 
> Objective-C.   The end result should be interchangeable with the 
> Objective-C implementation.

The current implementation tries to conform to the description of the 
default behaviour of the KeyValueCoding protocol. There may be minor 
differences due to me not understanding the documentation.

>
> That is, if I start with a class implemented in Objective-C and port 
> it to Python or vice-versa, the behavior from the context of K/V 
> coding should be identical.

Isn't it? The only difference between Objective-C and Python should be 
that the accessor method for reading an attribute is named 
'get_attribute' instead of 'attribute'. This necessary due to a 
semantic difference between Python and Objective-C. In Objective-C 
attributes are in a different namespace from methods, in Python they 
are not.

The common idom for "dumb" attributes in Objective-C seems to be:

	-myAttribute
	{
		return myAttribute
	}

	-getMyAttribute: value
	{
		[myAttribute autorelease];
		myAttribute = [value retain];
	}

You cannot translate this into Python without at least some changes to 
the code, in Python you cannot have a method and instance variable 
named 'myAttribute'. I'd do it like this:

	def getMyAttribute(self):
		return self.myAttribute

	def setMyAttribute(self, value):
		self.myAttribute = value

Ronald

Re: [Pyobjc-dev] Key/Value Coding

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

On Thursday, 14 August, 2003, at 20:19, b.bum wrote:

> Right -- it is of my opinion that the support for K/V coding as 
> presented in PyObjC should follow the rules of Objective-C as closely 
> as possible.  Hence, a callable attribute in the path should be called 
> and the value returned.  If the callable returns a callable -- then 
> that callable is returned.

To be pedantic: the rules in Objective-C is that methods get called, 
and instance variables get used as is. The current implementation in 
PyObjC does the same thing, it is possible to distinguish methods from 
attributes that happen to be callable.

Ronald

Re: [Pyobjc-dev] Key/Value Coding

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

On Thursday, 14 August, 2003, at 21:34, Pierce T. Wetter III wrote:
>
>> I'm going to roll back Bill's patch, it's not very usefull just 
>> before a 1.0 release. I'm going to look at the unittest to check if 
>> they add tests that should be added to the other KVC unittest files.
>
>  Actually, its a trivial change to get "key" to work as well. I sent 
> changes independently to bill that fix most of the broken unit tests, 
> except the ones where python is subclassing. In that case, the objects 
> aren't getting built for some reason, so I'll have to pass on those.

It may be trivial to get this to work, but not necessarily correct. In 
python the accessor methods are named 'get_value' and 'set_value' (or 
the camelcase variations of those), using accessors named like an 
attribute would be confusing.

BTW. The reason I'll roll back Bill's patch is that it introduces code 
that doesn't seem to serve a usefull purpose. If you use a mixin to add 
Objective-C style key-value coding, you may as well use a subclass of 
NSObject. Furthermore, the code won't work in the first place because 
the implementation for OC_PythonObject already contains implementations 
for those methods that don't (and shouldn't) check if the Python object 
happens to implement these methods as well.

  Ronald

[Pyobjc-dev] Recent change to K/V coding

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

The only change I made was the addition of KeyValueCodingMixIn -- a 
class in KeyValueCoding that can be mixed into any pure python class to 
add valueForKey_(), takeValue_forKeyPath_(), etc...    Useful, but easy 
to duplicate, certainly.

The one change I would like to see-- that I feel is very important-- is 
to fix the callable behavior such that it is inline with Objective-C.   
The end result should be interchangeable with the Objective-C 
implementation.

That is, if I start with a class implemented in Objective-C and port it 
to Python or vice-versa, the behavior from the context of K/V coding 
should be identical.

b.bum

Re: [Pyobjc-dev] Key/Value Coding

[Zachery B. <zb...@ur...>]

On Thursday, August 14, 2003, at 02:19 PM, b.bum wrote:

> Right -- it is of my opinion that the support for K/V coding as 
> presented in PyObjC should follow the rules of Objective-C as closely 
> as possible.  Hence, a callable attribute in the path should be called 
> and the value returned.  If the callable returns a callable -- then 
> that callable is returned.
>
> It sounds confusing, but it really isn't.   Follow the path.... 
> evaluate each element through getKey().... if the thing returned is 
> callable, call it and return the result.... go to next element in path 
> w/whatever was returned and repeat.

Excellent. Like how Zope translates URL paths to object publishing 
(methods if parameter-less or attributes), or how TAL path expressions 
work. Sweet!

Zac

Re: [Pyobjc-dev] Key/Value Coding

[Pierce T. W. I. <pi...@tw...>]

On Thursday, August 14, 2003, at 11:52 AM, Ronald Oussoren wrote:

>
> On Thursday, 14 August, 2003, at 18:38, Pierce T. Wetter III wrote:
>
>>
>> On Tuesday, August 12, 2003, at 09:41 PM, b.bum wrote:
>>
>>> I committed a new Key/Value coding unit test and a bit of additional 
>>> functionality in the KeyValueCoding module within PyObjCTools.   It 
>>> includes a compiled module.
>>>
>>> The unit tests do not pass and are currently, more or less, a 
>>> feature request.
>>>
>>> The goal is to make PyObjC's key/value coding support compliant with 
>>> ObjC to the point where Python, ObjC or mixed PyObjC instances can 
>>> be transparently passed into K/V dependent functionality.   We need 
>>> this to fully support the increasing emphasis on Key/Value Coding 
>>> found within Mac OS X.
>>
>>  As a WO hacker, I love KVC, so having KVC support would be cool and 
>> possibly should be a python feature separate from pyobjc. I forsee 
>> some problems on the Python side because python doesn't have separate 
>> name spaces based on type.
>
> We already support KVC, NSKeyValueCoding protocol works from 
> Objective-C (both for plain python objects and hybrid objects) and 
> PyObjCTools.KeyValueCoding can be used to do KVC from Python in a more 
> Python-friendly way.
>
> As you noted, we cannot use exactly the same conventions for Python as 
> are used in Objective-C. The KVC support for python objects uses 
> 'getKey' and 'get_key' as the getter method for 'key' and 'setKey' and 
> 'set_key' as the setter method for 'key'.


> I'm going to roll back Bill's patch, it's not very usefull just before 
> a 1.0 release. I'm going to look at the unittest to check if they add 
> tests that should be added to the other KVC unittest files.

  Actually, its a trivial change to get "key" to work as well. I sent 
changes independently to bill that fix most of the broken unit tests, 
except the ones where python is subclassing. In that case, the objects 
aren't getting built for some reason, so I'll have to pass on those.

  Pierce

Re: [Pyobjc-dev] Key/Value Coding

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

On Thursday, 14 August, 2003, at 18:38, Pierce T. Wetter III wrote:

>
> On Tuesday, August 12, 2003, at 09:41 PM, b.bum wrote:
>
>> I committed a new Key/Value coding unit test and a bit of additional 
>> functionality in the KeyValueCoding module within PyObjCTools.   It 
>> includes a compiled module.
>>
>> The unit tests do not pass and are currently, more or less, a feature 
>> request.
>>
>> The goal is to make PyObjC's key/value coding support compliant with 
>> ObjC to the point where Python, ObjC or mixed PyObjC instances can be 
>> transparently passed into K/V dependent functionality.   We need this 
>> to fully support the increasing emphasis on Key/Value Coding found 
>> within Mac OS X.
>
>  As a WO hacker, I love KVC, so having KVC support would be cool and 
> possibly should be a python feature separate from pyobjc. I forsee 
> some problems on the Python side because python doesn't have separate 
> name spaces based on type.

We already support KVC, NSKeyValueCoding protocol works from 
Objective-C (both for plain python objects and hybrid objects) and 
PyObjCTools.KeyValueCoding can be used to do KVC from Python in a more 
Python-friendly way.

As you noted, we cannot use exactly the same conventions for Python as 
are used in Objective-C. The KVC support for python objects uses 
'getKey' and 'get_key' as the getter method for 'key' and 'setKey' and 
'set_key' as the setter method for 'key'.

I'm going to roll back Bill's patch, it's not very usefull just before 
a 1.0 release. I'm going to look at the unittest to check if they add 
tests that should be added to the other KVC unittest files.

Ronald

Re: [Pyobjc-dev] Key/Value Coding

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

Right -- it is of my opinion that the support for K/V coding as 
presented in PyObjC should follow the rules of Objective-C as closely 
as possible.  Hence, a callable attribute in the path should be called 
and the value returned.  If the callable returns a callable -- then 
that callable is returned.

It sounds confusing, but it really isn't.   Follow the path.... 
evaluate each element through getKey().... if the thing returned is 
callable, call it and return the result.... go to next element in path 
w/whatever was returned and repeat.

b.bum

On Thursday, August 14, 2003, at 12:38 PM, Pierce T. Wetter III wrote:

>
> On Tuesday, August 12, 2003, at 09:41 PM, b.bum wrote:
>
>> I committed a new Key/Value coding unit test and a bit of additional 
>> functionality in the KeyValueCoding module within PyObjCTools.   It 
>> includes a compiled module.
>>
>> The unit tests do not pass and are currently, more or less, a feature 
>> request.
>>
>> The goal is to make PyObjC's key/value coding support compliant with 
>> ObjC to the point where Python, ObjC or mixed PyObjC instances can be 
>> transparently passed into K/V dependent functionality.   We need this 
>> to fully support the increasing emphasis on Key/Value Coding found 
>> within Mac OS X.
>
>  As a WO hacker, I love KVC, so having KVC support would be cool and 
> possibly should be a python feature separate from pyobjc. I forsee 
> some problems on the Python side because python doesn't have separate 
> name spaces based on type.
>
>  That is:
>     class.method.method.value
> .....

Re: [Pyobjc-dev] Key/Value Coding

[Pierce T. W. I. <pi...@tw...>]

On Tuesday, August 12, 2003, at 09:41 PM, b.bum wrote:

> I committed a new Key/Value coding unit test and a bit of additional 
> functionality in the KeyValueCoding module within PyObjCTools.   It 
> includes a compiled module.
>
> The unit tests do not pass and are currently, more or less, a feature 
> request.
>
> The goal is to make PyObjC's key/value coding support compliant with 
> ObjC to the point where Python, ObjC or mixed PyObjC instances can be 
> transparently passed into K/V dependent functionality.   We need this 
> to fully support the increasing emphasis on Key/Value Coding found 
> within Mac OS X.

  As a WO hacker, I love KVC, so having KVC support would be cool and 
possibly should be a python feature separate from pyobjc. I forsee some 
problems on the Python side because python doesn't have separate name 
spaces based on type.

  That is:
     class.method.method.value

  is not the same thing as:

     class.method().method().value

  For instance, being new to python, but used to ObjC I tried to code:

    class example:

	def __init__(self):
		self.instancevar=1

      def instancevar(self)
		return self.instancevar

   Which doesn't work, because you can't have an instance variable and a 
class method with the same name, because they're stored in the same 
dictionary.

    Instead:

    class example:

	def __init__(self):
		self.instancevar=1

      def getInstancevar(self)
		return self.instancevar

   works because it avoids the name collision.

  So KVC can't use the same rule set on both Python and ObjC.

   In fact, that's why your first test is failing, which you can see if 
you change the error message from:

     raise KeyError, "Key %s does not exist"%(key,)

to

     raise KeyError, "Key %s does not exist on obj %s"%(key,obj)

KeyError: 'Key indirectString does not exist on obj <bound method 
KVPyPath.indirectHead of <__main__.KVPyPath instance at 0x1e6170>>'

  directHead.indirectString returns the indirectString method, not the 
instance variable, so then the recursion breaks.

   So getKey() needs to be tweaked such that it looks at the result and 
if the result is callable,
  then it returns attribute(), otherwise it just returns the attribute. 
However, you're officially at the frontier of my python knowledge.


Pierce

P.S.

  I think Python people might find KVC confusing, since KVC would have a 
very similar but different syntax to python. However, I think the way 
to sell it to them is that its useful with config files and other tools 
where () is in appropriate:

config.subsystem.setting = 1

The config file doesn't need to know what's under config, subsystem, or 
setting, and any or all of these can be instance variables instead of 
functions.

Re: [Pyobjc-dev] Suggested Documentation change

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

On Wednesday, 13 August, 2003, at 19:49, Pierce T. Wetter III wrote:

> Currently:
>
>
> The basics
>
> The code for loading a framework and exporting its classes is pretty  
> simple:
>
[...]

>
> Change to:
>
> The basics
>
[ improved version ]

Thanks for the feedback.

> Don't forget to import the frameworks that are used by your framework  
> before calling objc.loadBundle. This is necessary to arrange for the  
> helper code for these modules (if there is any) to be loaded.
>
> Pierce
>
> P.S.
>
>   I'm not sure about the: "Don't forget to import the frameworks that  
> are used by your framework before calling objc.loadBundle." line. I  
> did a quick test and found out that the framework loading mechanism  
> seemed to be able to figure it out even if I didn't load all the  
> required frameworks. It used to be true under Rhapsody, but X seems to  
> have fixed this.

I'll try to clarify this in the documentation. There is a PyObjC  
problem w.r.t. fixing the method signatures for a number of methods.  
The wrappers for AppKit and Foundation update the method signatures for  
a number of methods with input/output pass-by-reference arguments.  
Those updates don't work if the method list for a class has already  
been scanned. Importing the PyObjC modules in the right order solves  
this problem, and I have correctly fixing this problem on my todo list.


Ronald
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct; 
> at.aspnet_072303_01/01
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

Re: [Pyobjc-dev] Some PyObC tweaks for using EOF and custom frameworks

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

On Wednesday, August 13, 2003, at 13:29, Pierce T. Wetter III wrote:
> So I removed by [obj self] call from pythonify_c_value, and I used  
> this instead:
>
> 		 
> objc.classAddMethods(EOFault,[Foundation.NSObject.__pyobjc_PythonObject 
> __])
>
> And that worked on single faults, but not array faults.

Are array faults implemented directly via EOFault or is there some  
other class to stand in for 'em?

> I also got "None" for object.description() on a single fault. So it  
> really only partially
> worked.

Odd.

Posing could completely hose this....   are you doing the  
classAddMethods() immediately upon loading EOAccess [which defines  
EOFault, IIRC]?

b.bum