[Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343

[Michael Hudson]

Walter Dörwald <walter at livinglogic.de> writes:

> Am 07.07.2005 um 20:00 schrieb Guido van Rossum:
>
>>>> +1 on @contextmanager
>>
>> +1.
>>
>> [__enter__, __exit__]
>>
>>>>> These names should be changed to __beginwith__ and __endwith__.
>>>>>
>>
>> -1.  The PEP has had an extensive review period and several
>> alternatives were discussed and rejected. These names are clear, they
>> *do* match, and as Fred says the __*__ namespace has lots of room.
>>
>> Also, the PEP was accepted with these names. Now, if it was accepted
>> with a major flaw or some semantics left unspecified,
>
> What is still unspecified (or at least not explicitely mentioned) in  
> the PEP is the lifetime of VAR in:
>
>          with EXPR as VAR:
>              BLOCK
>
> Does VAR overwrite or shadow any previous values of VAR? 

Yup!  Or at least in my half-an-implementation, that's what happens.

(PEP 343 is a lot harder to implement then you might think, btw -- the
stack discipline around finally: statements is a bit mind-bending).

> I.e. will VAR still exist after the end of the block with its value
> the return value of __enter__() or will it revert to the previous
> value (if any)?

Eh, no.  Where would you store the old value?

> I'd prefer the later although interpreting the translation of
>
>          with EXPR as VAR:
>              BLOCK
>
> into
>
>          abc = EXPR
>          exc = (None, None, None)
>          VAR = abc.__enter__()
>          try:
>              try:
>                  BLOCK
>              except:
>                  exc = sys.exc_info()
>                  raise
>          finally:
>              abc.__exit__(*exc)
>
>
> literally would indicate the former.

Please continue to interpret it like that :)

Cheers,
mwh

-- 
  > Why are we talking about bricks and concrete in a lisp newsgroup?
  After long experiment it was found preferable to talking about why
  Lisp is slower than C++...
                        -- Duane Rettig & Tim Bradshaw, comp.lang.lisp