From: Michael Rudolf on
Am 04.03.2010 17:32, schrieb Jean-Michel Pichavant:
> It looks like to me that 'with' statements are like decorators: overrated.

Oh no, you just insulted my favourite two python features, followed
immediately by generators, iterators and list comprehensions / generator
expressions :p

No, really: they *are* great ;D

From: Jean-Michel Pichavant on
Michael Rudolf wrote:
> Am 04.03.2010 17:32, schrieb Jean-Michel Pichavant:
>> It looks like to me that 'with' statements are like decorators:
>> overrated.
> Oh no, you just insulted my favourite two python features, followed
> immediately by generators, iterators and list comprehensions /
> generator expressions :p
> No, really: they *are* great ;D
> Regards,
> Michael
They are great, and because of that greatness some of us, including me,
tend to use them where there's no point doing so.
I would never state that decorators are useless anyway, not in this
list, I value my life too much :-) (I'll give it a try in the perl list)

From: Alf P. Steinbach on
* 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:
>>>> 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() 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.


- Alf

From: Mike Kent on
On Mar 3, 10:56 am, "Alf P. Steinbach" <al...(a)> wrote:
> * Mike Kent:
> > What's the compelling use case for this vs. a simple try/finally?
> if you thought about it you would mean a simple "try/else". "finally" is always
> executed. which is incorrect for cleanup
> by the way, that's one advantage:
> a "with Cleanup" is difficult to get wrong, while a "try" is easy to get wrong,
> as you did here
>    ---
> another general advantage is as for the 'with' statement generally
> >    original_dir = os.getcwd()
> >    try:
> >        os.chdir(somewhere)
> >        # Do other stuff
> also, the "do other stuff" can be a lot of code
> and also, with more than one action the try-else introduces a lot of nesting
> >    finally:
> >        os.chdir(original_dir)
> >        # Do other cleanup
> cheers & hth.,
> - alf

Wrong? In what way is my example wrong? It cleanly makes sure that
the current working directory is the same after the try/finally as it
was before it. Suboptimal, perhaps, in that the chdir in the finally
part is always executed, even if the chdir in the try part failed to
change the working directory.

That is a clear advantage to the code you presented, in that you have
the ability to register an 'undo' function only if the 'do' code
succeeded. Your code also avoids a problem with many nested try/
finally blocks. But for the simple chdir example you gave, I think
'wrong' isn't the word you were looking for regarding the try/finally
example I gave.

Anyway, I'll keep your code in mind the next time I want to avoid a
bunch of nested try/finally blocks.
From: Mike Kent on
On Mar 4, 12:30 pm, Robert Kern <robert.k...(a)> wrote:

> He's ignorant of the use cases of the with: statement, true.

<humor> Ouch! Ignorant of the use cases of the with statement, am I?
Odd, I use it all the time. </humor>

> Given only your
> example of the with: statement, it is hard to fault him for thinking that try:
> finally: wouldn't suffice.

<humor> Damn me with faint praise, will you? </humor>

I'm kinda amazed at the drama my innocent request for the use case
elicited. From what I've gotten so far from this thread, for the
actual example Mr. Steinbach used, the only disadvantage to my counter-
example using try/finally is that the chdir in the finally part will
always be executed, even if the chdir in the try part did not
succeed. I concede that, and was aware of it when I wrote it. For
the simple example given, I did not consider it compelling. A more
complex example, that would have required multiple, nested try/finally
blocks, would show the advantages of Mr Steinbach's recipe more

However, I fail to understand his response that I must have meant try/
else instead, as this, as Mr. Kern pointed out, is invalid syntax.
Perhaps Mr. Steinbach would like to give an example?
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11
Prev: Few early questions on Class
Next: SOAP 1.2 Python client ?