Python vs Java garbage collection?

[Beni Cherniavsky]

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 :-?

> The design is completly orthogonal to any refcount or memory management details.
>
> Though it begins to work it's still in the flow the more i get to know the
> python core internals.Btw, it's a pleasure reading and modifying the core
> python C code.I didn't touch C/C++/Java much since i got to know python.
> I was suprised at the readability of the core code.I try to keep the
> changes as minimal as possible.
>
> 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?  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...

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

> 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?
    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__.

> 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``)?

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

> There will be no closing tags, though.
>
> The whole idea is to build on indentation as opposed to funny closing
> characters or tags.The open/close and acquire/release protocols are
> a variation of this theme.
>
> 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 %-).

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