Python vs Java garbage collection?

[holger krekel]

Beni Cherniavsky wrote:
> On 2002-12-30, holger krekel wrote:
> 
> > I am currently experimentally implementing something along these lines.
> > It does require introducing new syntax along with a new object protocol.
> > I currently call it 'Indented Execution' as it allows an object to define
> > __enter__ and __leave__ methods wrappingexecution of 'its' indented block.
> >
> 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

> > A preview example (could still change) of what my experiments accomplish:
> >
> >   <autoclose f1=open('/etc/passwd') f2=open('/etc/shadow')>
> >       data1 = f1.read()
> >       data2 = f2.read()
> >
> >   # f1 and f2 will be closed here, even if there was an exception
> >   # in the indented code block. Any exception will be propagated
> >   # of course.
> >
> > 'autoclose' is the name of an object which provides
> >
> >   def __enter__(self, **kw):
> >       "keyword arguments containing e.g. the above 'f1' and 'f2'"
> >
> Why the keyword args?  Is the object supposed to poke with the calling
> scope's variables to bind them there?

I have changed this already.  __enter__ doesn't anymore get any arguments,
It's simply invoked.  

>  Or are the names passed just for
> making pseudo-xml applications possible?  But note that the content of the
> "element" is not passed by you so xml-like construction of data becomes
> inconvenient...

This is now possible.  I'll make available a one screenful
implementation of a simple and convenient pythonic xml-construction 
kit. (XML-syntax syntactically integrated with python, no
intermediate language, no "templating engine", pure python fun).

It also allows to spot and handle errors in parts of the 
construction lazily.  Encapsulating exception processing 
in nearby handler objects is truly powerful.  After all, 
the quality of a program shows when errors occur. 

> >   def __leave__(self):
> >       """called if execution leaves the indented block"""
> >
> How about passing some context info to __leave__, at least the objects to
> be closed?  

The __leave__ and __except__ methods have other means of getting
to bindings in namespaces.  Due to python's internals it is hard (and 
IMO not desirable) to *change* name bindings in execution namespaces
(especially in the local scope). 

Moreover, I like the convience and ease of saying:

    class lock(threading._RLock):
        __enter__ = threading._RLock.acquire
        __leave__ = threading._RLock.release

and then

    class danger:
        def __init__(self):
            self.lock = lock()
        def invoke(self):
            <self.lock>
                print "critical stuff"

such "critical regions" work now with exactly the
above code. 
    
> Otherwise, autoclose has the burden of remembering them
> himself, which also means that a new autoclose should be allocated each
> time the code is executed (i.e. it's a class, not an object).

That's currently the case, right.  I played around with other
possibilities but couldn't come up with something easy. 

> > i didn't see an easy way to reuse the 'SETUP_FINALLY/END_FINALLY'
> > bytecodes so i introduced new bytecodes.They might go away later.
> 
> I'm not familiar with the internals, but since your fanctionality can
> probably be defined as equivallent to some python code, e.g.::
> 
>     # sticking to your semantics but see my comments above
>     autoclose.__enter__(f1=open('/etc/passwd'), f2=open('/etc/shadow'))
>     # by the way, what if the second open raise an exception?

good question! noted. 

>     try:
>         data1 = f1.read()
>         data2 = f2.read()
>     finally:
>         autoclose.__leave__()
> 
> you can probably implement in terms of it - you should emit both the
> TRY/FINALLY opcodes *and* the code to call __enter__/__leave__.

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).  

> > But more about this when i have figured out the gory details of
> > local namespaces & compiler passes among others. First i want
> > to get my unit tests to pass :-)
> >
> > It's not only a conincedence that this resembles xml-syntax.Actually
> > i started out using pythonic ':' syntax but this had a few problems (syntax
> > ambiguity among others).
> 
> I think that adding a ':' after the '>' is still more readable.  Without
> it, the following lines look as just hanging in the air (to me).  BTW, do
> you allow one-line code on the same line (e.g. ``<autoclose f=x>: foo``)?

yes, that works like expected.  But because xml-syntax is so familar i 
don't currently want extra ':' noise.   
 
> > Besides, 'Indented Execution' could allow to define
> > xml-documents and conversions with a very familiar (python + xml) syntax.
> >
> Interesting thought.  But do you intend to use it?

I just need some time ...

> If you want it to be
> usable to construct data structures, you miss the part of also passing the
> inner code to the controlling object, in some way (as code object? that
> would allow almost full macro powers but most would consider the xml
> notation improper for that).

I started out in the code-object direction. I soon realized this was
too complicated. This gets you into all kinds of scope-problems 
at least.  And most people wouldn't know what to do with a code 
object except executing it and wrapping a try-finally construct
around it :-)

So i began to wonder which kind of problems _i_ would like to 
solve with it.  In effect, everytime i have to implement behaviour
before and/or after something executes and also do something in the
face of exceptions the IEXEC protocol should help. It enables
abstracting away this behaviour in nearby 'handler' objects. 

> > ok, that's enough for now.i couldn't hold myself telling you about
> > this fun project :-) It's actually motivated by recent discussions here
> > on c.l.py and a suggestion of Michael Hudson (who aims to provide a
> > new 'with' keyword achieving a significant subset of my goals).
> >
> Fun indeed.  I'd like to help but I'm probably too busy (exam period
> approaching %-).

Sometimes fun beats business.

anyway, I am open for co-developing and thinking 
about this stuff. 

regards,

    holger