Walter Dörwald <[EMAIL PROTECTED]> 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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
