From: Michael Hudson <mwh@python.net>
Date: Wed Nov 26, 2003  15:39:58 Europe/London
To: Bill Soudan <bill@soudan.net>
Subject: Re: PEP 310/object lifetimes?

Bill Soudan <bill@soudan.net> writes:

> On 26 Nov 2003, Michael Hudson wrote:
>
>> Is this the same Bill Soudan as in libicq?  That stirs some old
>> memories...
>
> Whoa... that's right, you were the Python guy that wrote the bindings!
> Ah, interesting how our paths cross again.  Great memory.

:-)  What happened to libicq?

> Since the libicq days, I've mainly been C++ but recently doing more
> and more in Python.  My lastest task was a performance testing
> system for our software here at work coded entirely in Python.  The
> main loop was a bit too much for Python to handle, so I rewrote it
> in C++ and used sip to make some bindings.  All in all, it worked
> out superbly - complicated setup/teardown bits still in Python,
> simple tight main loop ported almost line-by-line (!) from Python to
> C++.

!, indeed.  There should be many less lines in the Python version :-)

> I'd like to see us do this will all our software, personally, Python
> is a dream to develop with and maps so well to C++.  My three nits
> with the current system: sip won't propagate exceptions from from
> Python->C++ (though it will the other way around), you have to write
> special sip versions of your header files, and I wish I could
> control object lifetimes explicitly in Python.  I don't like doing a
> 'del last_reference_i_think' and hoping the implementation will
> delete the underlying object.

I think you need to let go a bit.

>> I think it's a *different* solution to a different problem.
>>
>> While the "Resource Acquistion is Initialization" pattern works pretty
>> well in C++, I'm not sure it would work so well in Python.  Maybe it's
>> just my distrust of __del__ methods.
>
> It's definitely a different solution, but your __enter__/__exit__
> mechanism is served just as well (in my mind) by __init__/__del__.

Bear in mind that one of the use cases is:

with lock:
    # have the lock here
# released here

*that* doesn't fit the __init__/__del__ pattern.  Yeah, you could do

class Locker:
     def __init__(self, lock):
         self.lock = lock
         self.lock.acquire()
     def __del__(self):
         self.lock.release()

but that seems false.

> And since I've always been of the opinion Python's a little crazy
> already with the large number of __special__ methods, re-using
> existing is a plus.

Well, here I have a 180 degree difference to you: I *abhor* the use of
the same notation for more than one task.

> Finally, the concept is well known by C++ programmers, I use it all
> the time. It'd be nice if Python supported the same, especially for
> cases like me where you're working with C++ bindings and you _need_
> the underlying C++ object to go away.

Why do you "_need_ the underlying C++ object to go away"?

> I wanted to discuss it with you since I see it as a two-birds-one-stone
> type of thing.  Actually, maybe more, another use case I was thinking
> about:
>
>   with o = ReallyExpensiveObject():
>     # ...
>
>   # no more ReallyExpensiveObject

What if "# ..." is somelist.append(o)?

> To me, this feature is very 'Python': simple, powerful, elegant.

For all that you say you like Python, I think you might like it even
more if you stopped trying to write C++ in it...

Cheers,
mwh

-- 
   Gevalia is undrinkable low-octane see-through only slightly
   roasted bilge water. Compared to .us coffee it is quite
   drinkable.                                      -- MŒns Nilsson, asr