[Patches] [ python-Patches-538395 ] ae* modules: handle type inheritance

Wed, 03 Apr 2002 01:29:44 -0800

Patches item #538395, was opened at 2002-04-02 21:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=538395&group_id=5470

Category: Macintosh
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Donovan Preston (dsposx)
Assigned to: Jack Jansen (jackjansen)
Summary: ae* modules: handle type inheritance

Initial Comment:
The gensuitemodule script creates Python 
classes out of AppleScript types. It keeps track of 
properties in _propdict and elements in _elemdict. 
However, gensuitemodule does not accurately 
replicate the AppleScript inheritance heirarchy, and 
__getattr__ only looks in self._propdict and 
self._elemdict, therefore not finding elements and 
properties defined in superclasses.

Attached is a patch which:

1) Correctly identifies an AppleScript type's 
superclasses, and defines the Python classes 
with these superclasses. Since not all names may 
be defined by the time a new class is defined, this 
is accomplished by setting a new class' 
__bases__ after all names are defined.

2) Changes __getattr__ to recurse superclasses 
while looking through _propdict and _elemdict.

It also contains small usability enhancements 
which will automatically look for a .want or .which 
property when you are creating specifiers.

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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-04-03 11:29

Message:
Logged In: YES 
user_id=21627

cvs update will keep a copy of the original file (the one
you edited) if it has to merge changes; it will name it
.#<file>.<version>. So in no case cvs will destroy your
changes. Normally, merging works quite well. If it finds a
conflict, it will print a 'C' on update, and put a conflict
marker in the file. The stuff above the ===== is your code,
the one below is the CVS code.

If you want to find out what cvs would do, use 'cvs status'.

If you don't want cvs to do merging, the following procedure
will work

cvs diff -u >patches
patch -p0 -R <patches
cvs up
patch -p0 <patches

Notice that the last patch may report rejected hunks in case
of conflicts.

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

Comment By: Donovan Preston (dsposx)
Date: 2002-04-03 08:50

Message:
Logged In: YES 
user_id=111050

Jack:

Thanks a lot for your comments! You're right on target on most of them.

Not sure why I didn't make a context diff this time -- last time it was screwed up, I thought it was because of that, but it was really just the tabs vs spaces issue. cvs is still very new and ugly to me.

I did indeed manually apply your patches to my tree, because I was afraid of what an update would do to the production code that my boss would kill me if broke... I'll do an update on another machine and reapply the patches to that checkout. Is there any way I can get a log of what the update has done to my files, so I can check them manually?

Hmm. I hadn't thought about passing the module itself; how would I get a reference to a package from inside of that package's __init__.py? From aetools, I can get away with saying __import__(modulename), but inside of __init__.py, what do I use to get a reference to the module that __init__.py is initializing?

Finally, after thinking about it a bit, Fourth and fifth points may be better solved by a construct like this:

(applescript type bar inherits from foo)

bar._elemdict = copy(foo._elemdict)
bar._elemdict.update({ dict of new keyword/class mappings })

This has the advantage of flattening out the inheritance tree again, since all elements and properties each class needs to know about are in it's own copy of _elemdict and _propdict, and therefore no Python inheritance relationship needs to be made.

I had wanted to build the inheritance heirarchy properly, and dynamically look through bases, because it was "cool" but in retrospect, speed is more important :-)

Donovan

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-04-02 23:47

Message:
Logged In: YES 
user_id=45365

Donovan, I love the functionality of your patch, but I would humbly request you make a couple of changes. Alternatively I'll make them, but that will delay the patch (as I have to find the time to do them).

First: please make it a context diff (cvs diff -c), as straight diffs are too error prone for moving targets. There are also mods I can't judge this way (such as why you moved the 'utxt' support in aepack.py to a different place. Or is this a whitespace mismatch?)

Second: you've diffed against the different version than against which you've patched. See gensuitemodule, for instance: it appears as if you've modified 1.22 but diffed against 1.21. Maybe you applied my 1.21->1.22 by hand without doing a cvs update? I think a cvs update (plus some manual work;-) should solve this.

Third: the passing of modules by name (to the decoding routines) seems error prone and not too elegant. Can't you pass the modules themselves in stead of their names? It would also save extra imports in the decoders.

Fourth: assigning to __bases__ seems like rather a big hack. Can't we generate the classes with a helper class, similarly to the event helper class in the __init__.py modules: FooApp/Foo_Suite.py would contain the class foo sketched above, and FooApp.__init__.py would contain
import othersuite.superfoo
import Foo_Suite.foo
class foo(Foo_Suite.foo, othersuite.superfoo):
	pass

Fifth, and least important: you're manually iterating over the base classes for lookup. Couldn't we statically combine the _propdict and _elemdict's of the base classes during class declaration, so that at lookup time we'd need only a single dictionary lookup? The "class foo" body in __init__.py would then become something like
	_propdict = aetools.flatten_dicts(
		foosuite.foo._propdict,
		othersuite.superfoo._propdict)
and similar for elemdict.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=538395&group_id=5470