Python vs Java garbage collection?

Thu Jan 9 19:31:44 EST 2003

On 2003-01-08, holger krekel wrote:

> Beni Cherniavsky wrote:
> > Hey!A sort of macros!  Tasty :-)  When could I lay my hands on it :-?
>
> It's actually working since today! It's a patch to Python-2.2.2 at
> parser, compiler, bytecode and VM-level. But it's seemlessly compatible
> because it doesn't change syntax or semantics of any (existing) python
> program.
>
> It's still called 'Indented Execution' and allows (among other usages)
> to nicely do "timely finalization" independent of memory management details.
> If you want to have a preliminary look, go here:
>
>   http://codespeak.net/moin/moin.cgi/IndentedExecution
>
Nice.  This exaplains much.  Grabbed a copy and will play with it...
[BTW, test_iexec.py includes two classes with same name
IEXEC_WithKeywords, you'll probably want to fix it]

I certainly like the power of this thingie.  However there are points in
the interace design which I don't like.  The basic point of my objections
is that you are trying to lump together two main very different uses:

1. One thing that you want to do is to execute code with pre/post/except
   handling.  For this use, the "attributes" design is problematic.  Most
   importantly, my instincts tell me that the execution handler should be
   aware of the names you choose for your variables (e.g. in the file
   example).  There is also the danger of accidentally clashing with an
   attribute of the execution handler.  See discussion below.

   - The fact the inner code is not executed when the execution handler is
     None looks like an attempt to also abstract if statements, not only
     try.  (If it's a sequence, it should be executed multiple times,
     shouldn't it? <wink>)  This looks too specialized (must be decided
     beforehand) -- I would instead say that if the execution handler has
     a e.g. __cond__ method, it's called and the block is executed only if
     it returned a true result.  This is not very elegant either, so I
     still think the code object approach would be easiest to use.

   - The copying from local namespace into the object is reminiscent of
     the class statement and is quite elegant.  So I'm not sure it's bad.

2. The other thing is allowing data expressions with significant
   indentation and an xml-like syntax.  Here it does make sense to let the
   execution handler know the names of the bindings.  However it doesn't
   make much sense to expose them in the local namespace -- why would I
   care that ul="square" when I compose a list item inside it?

   - This can be solved by using keyword arguments when creating the
     execution handler instead of using IEXEC's "attribute" syntax.  The
     loss of xml syntax where it's most appropriate is a drawback...

   - The most problematic thing here the __icontent__.  The idea is nice -
     to make a list of the values written as expressions on separate
     lines.  A similar idea is the bassic of the Python Template Language
     in http://www.mems-exchange.org/software/quixote/.  There they
     automatically suppress None values; maybe you should adopt this.
     Another difference is that in PLT the special meaning for lone
     expression is for the whole function, whereas in IEXEC it doesn't
     effect the substatements.  This is good since it allows to express
     nested structure.

     - The fact that expressions are saved is contrary to one's habits of
       reading Python code; this will only be important in some execution
       handlers but the reader can't be sure.  This is another reason to
       separate the two uses.  I'm not sure how to do it nicely, though.

     - Storing __icontent__ in the caller's namespace is ugly.  Putting
       it on the execution handler is problematic too because the values
       would be ratained, which might not be what one wants.  Another idea
       is passing the list of unassigned values to a new method of the
       execution handler, so this saving becomes optional.

     - Reading xml.py solved my wander how can the <html> statement return
       any data -- it can't it stores it for later use.  On one hand, this
       is pythonic.  On the other, it makes the code awkward.  The most
       troublesome part is that the sub-tags, being implemented as IEXEC
       statements, are not part of the __icontent__.  Worst of all, they
       are executed before the anassigned expressions are processed.  This
       makes getting something like xml.py right very hard.

       - I think the best solution is to drop the construction of the
         __icontent__ list and make each unassigned expression call a
         method of the execution handlerd (e.g. __takeval__) with the
         expression's value, immediately after it was computed.  The
         benefit is that order is preserved with respect to statements in
         the indented block.  Another benefit is the ability to call the
         method manually from inside conditionals/loops - it would be
         hard to generate e.g. a variable length table in the __icontent__
         approach.  This prompts for a non __underscoped__ method name,
         `append` is natural.

> The problem is with END_FINALLY (the finalizing bytecode for the
> TRY/FINALLY construct).It's not that easy to call the
> leave-method in the face of an exceptional state. Because you
> don't know much about the stack and thus can't easily get to
> any handler object (which needs to be on the stack).
>
I'll trust you know what you are doing better than I do :-)

-- 
Beni Cherniavsky <cben at tx.technion.ac.il>