[Zope-dev] Trying to design a PythonMethod Product

Martijn Faassen faassen@vet.uu.nl
Sat, 14 Aug 1999 00:13:11 +0200


Christopher Petrilli wrote:

[replacing manipulating the AST with bytecodehacks]
> I would be curious of the performance difference as well.  We wrote our
> stuff LONG before anyone had developed anything better, and it was heavily
> optimized. 

Is your stuff in C? It would probably be more straightforward to do something
like bytecodehacks in C than it is manipulating any type of tree. And
I think manipulating arrays in C can be a lot faster than manipulating
a tree full of pointers. So a performance comparison would be indeed
very interesting.

> >> Actually, we talked about just limiting the "instruction counter" so that
> >> you could catch anything that was taking an excessively long period of
> > time
> >> to execute.  Say 1M byte-codes?  This avoids having to worry about
> >> individual flow constructs.
> >
> > Sounds great!  How? :-)
> 
> I'll have to look, but I recall Jim explaining a way to do this, so I'm sure
> it's possible.

It's definitely possible; as I mentioned before, look at the discussion on
Python microthreads on comp.lang.python. Will Ware has implemented this,
and it consists of loading a module, no hacking of the Python main
engine itself. Of course that module *does* contain a hacked up version of
the Python interpreter, so it raises maintainability concerns, but apparently
the plan is to merge this in with the Stackless Python project, which 
seems to have at least a chance of making it into the main Python
distribution.

> > This has led me to extend my original idea.  I *really* dislike requiring a
> > separate Zope object for every method in a module of external methods, and I
> > think it would be even more annoying when the actual code is web-managed.
[snip]
> I disagree strongly here.  An "method" is an object, and it might reside in
> a container (which one might call a Module), but modules are namespaces, not
> objects in the sense that you're using them.   I think your goals, while
> admirable, are substantially large enough in scope to mire down the
> implementation with additional chrome that may or may not be useful.  I'd
> recommend getting something very basic done before attempting the Holy
> Grail.

What about doing it both? Make the code web managed but allow a way to
edit it in the Python module way as well. Things like this are possible;
XML Document for instance allows some manipulating of the XML as a Zope tree,
but at the same time it represents itself as a plaintext document.

But I'd agree with Chris here that doing it the Zope way first is the
best way to go; and probably easiest.

> I very much think you should use the existing machinery, rather than
> designing your own new... it's just more variables to examine when trying to
> understand the isolation mechanisms.

But of course, if by using the existing machinery it is improved, that's
good. And often one can improve something existing better if one has tried
to implement it by oneself first. So the thinking is at least not waisted.

But I think we all agree on using the existing machinery as much as possible.

Regards,

Martijn