[Python-Dev] Re: Object finalization for local (ie function) scopes

[Paul Moore]

"Oliver Schoenborn" <oliver.schoenborn at utoronto.ca> writes:

> As mentioned in a discussion off list, I quite like 310. However, I
> also troweled the python-dev archives and didn't seen any discussion
> of anything related to the try/finally wrapping that I mentioned,

PEP 310 basically *is* about try/finally wrapping. Just not at
function level.

> and since the implementation could likely be cleaner and more
> performant if implemented in the interpreter directly, and would not
> require change to the language itself, I mentioned it here. But
> that's the only reason for coming to python-dev.

[...]

>> To summarise, I think you
>> should consider whether PEP 310 is what you need
>
> 310 is a good, fairly clean compromise.

Can you enumerate precisely how your proposal differs from PEP 310?
While I've not been following the technicalities of your discussions,
I get the impression that the main points are:

1. Delimits the scope of the construct by variable scope rather than
   introducing a new keyword.
2. Different "magic" method names.
3. Derives the objects to call the "release" method on, based on some
   sort of local variable scan (I don't follow this too well, so I
   apologise if I've described it badly).

Clearly, (2) is trivial. For (1), you save a keyword at the cost of
overloading 2 different behaviours on the variable scoping mechanism.
I'm not at all sure I can comment on (3), but my instinct says that it
is too magical - a direct violation of "explicit is better than
implicit".

In summary, I see PEP 310 as a cleaner, more explicit, less magical
variation of your proposal. (Of course, I would!)

>> (it's probably mode
>> Pythonic than overloading __del__ the way C++ does)
>
> I agree, that's certainly *not* what I would advocate. But since you bring
> it up, is there any reason why a new method like, say, __deterministic__,
> couldn't be added, and any class that has it means that interpreter calls
> that method upon scope exit if exception has been thrown *or* object
> unreachable?

Your semantics are very muddy here. I prefer something clear and
explicit - PEP 310's with construct calls the __exit__ method
*always*. No exceptions. The semantics are clear, and the behaviour is
simple. It's up to the user to write code that conforms to that
contract, but as the contract is so simple, that should be easy.

One of the problems with __del__ is that the semantics of when it is
called are complex and subtle. It seems to me that your proposal is
going to have the same problem. [Remember, that "object unreachable"
is a fairly subtle concept - you need to watch for exception frames
which still contain references to the function and its locals, etc,
etc.]

If you could take your proposal, and tease out the reasons why you
feel that PEP 310 does not satisfy the need you have, which your
proposal does, and list those reasons in a way that could be added to
PEP 310 (possibly as limitations, possibly as open questions, or
possibly even as proposed extensions) then that would be great.

Paul.
-- 
This signature intentionally left blank