A "scopeguard" for Python

[Alf P. Steinbach]

* Robert Kern:
> On 2010-03-04 10:56 AM, Alf P. Steinbach wrote:
>> * Robert Kern:
>>> On 2010-03-03 18:49 PM, Alf P. Steinbach wrote:
[snippety]
>>>
>>>> If you call the possibly failing operation "A", then that systematic
>>>> approach goes like this: if A fails, then it has cleaned up its own
>>>> mess, but if A succeeds, then it's the responsibility of the calling
>>>> code to clean up if the higher level (multiple statements) operation
>>>> that A is embedded in, fails.
>>>>
>>>> And that's what Marginean's original C++ ScopeGuard was designed for,
>>>> and what the corresponding Python Cleanup class is designed for.
>>>
>>> And try: finally:, for that matter.
>>
>> Not to mention "with".
>>
>> Some other poster made the same error recently in this thread; it is a
>> common fallacy in discussions about programming, to assume that since
>> the same can be expressed using lower level constructs, those are all
>> that are required.
>>
>> If adopted as true it ultimately means the removal of all control
>> structures above the level of "if" and "goto" (except Python doesn't
>> have "goto").
> 
> What I'm trying to explain is that the with: statement has a use even if 
> Cleanup doesn't. Arguing that Cleanup doesn't improve on try: finally: 
> does not mean that the with: statement doesn't improve on try: finally:.

That's a different argument, essentially that you see no advantage for your 
current coding patterns.

It's unconnected to the argument I responded to.

The argument that I responded to, that the possibility of expressing things at 
the level of try:finally: means that a higher level construct is superfluous, is 
still meaningless.



>>>>> Both formulations can be correct (and both work perfectly fine with
>>>>> the chdir() example being used). Sometimes one is better than the
>>>>> other, and sometimes not. You can achieve both ways with either your
>>>>> Cleanup class or with try: finally:.
>>>>>
>>>>> I am still of the opinion that Cleanup is not an improvement over try:
>>>>> finally: and has the significant ugliness of forcing cleanup code into
>>>>> callables. This significantly limits what you can do in your cleanup
>>>>> code.
>>>>
>>>> Uhm, not really. :-) As I see it.
>>>
>>> Well, not being able to affect the namespace is a significant
>>> limitation. Sometimes you need to delete objects from the namespace in
>>> order to ensure that their refcounts go to zero and their cleanup code
>>> gets executed.
>>
>> Just a nit (I agree that a lambda can't do this, but as to what's
>> required): assigning None is sufficient for that[1].
> 
> Yes, but no callable is going to allow you to assign None to names in 
> that namespace, either. Not without sys._getframe() hackery, in any case.
> 
>> However, note that the current language doesn't guarantee such cleanup,
>> at least as far as I know.
>>
>> So while it's good practice to support it, to do everything to let it
>> happen, it's presumably bad practice to rely on it happening.
>>
>>
>>> Tracebacks will keep the namespace alive and all objects in it.
>>
>> Thanks!, I hadn't thought of connecting that to general cleanup actions.
>>
>> It limits the use of general "with" in the same way.
> 
> Not really.

Sorry, it limits general 'with' in /exactly/ the same way.


> It's easy to write context managers that do that [delete objects from the namespace].

Sorry, no can do, as far as I know; your following example quoted below is an 
example of /something else/.

And adding on top of irrelevancy, for the pure technical aspect it can be 
accomplished in the same way using Cleanup (I provide an example below).

However, doing that would generally be worse than pointless since with good 
coding practices the objects would become unreferenced anyway.


> You put 
> the initialization code in the __enter__() method, assign whatever 
> objects you want to keep around through the with: clause as attributes 
> on the manager, then delete those attributes in the __exit__().

Analogously, if one were to do this thing, then it could be accomplished using a 
Cleanup context manager as follows:

   foo = lambda: None
   foo.x = create_some_object()
   at_cleanup.call( lambda o = foo: delattr( o, "x" ) )

... except that

   1) for a once-only case this is less code :-)

   2) it is a usage that I wouldn't recommend; instead I recommend adopting good
      coding practices where object references aren't kept around.


> Or, you 
> use the @contextmanager decorator to turn a generator into a context 
> manager, and you just assign to local variables and del them in the 
> finally: clause.

Uhm, you don't need a 'finally' clause when you define a context manager.

Additionally, you don't need to 'del' the local variables in @contextmanager 
decorated generator.

The local variables cease to exist automatically.


> What you can't do is write a generic context manager where the 
> initialization happens inside the with: clause and the cleanup actions 
> are registered callables. That does not allow you to affect the namespace.

If you mean that you can't introduce direct local variables and have them 
deleted by "registered callables" in a portable way, then right.

But I can't think of any example where that would be relevant; in particular 
what matters for supporting on-destruction cleanup is whether you keep any 
references or not, not whether you have a local variable of any given name.

And I think "with" is quite useful even with that restriction.


Cheers,

- Alf