List PEPs that can be rejected once this is accepted. This turned up

a surprise: PEP 319.
This commit is contained in:
Guido van Rossum 2005-06-01 21:01:11 +00:00
parent c76b8b40fc
commit b71b1ff13d
1 changed files with 31 additions and 0 deletions

View File

@ -19,6 +19,33 @@ Introduction
exception; these additions were first proposed in [2] and
universally approved of. I'm also changing the keyword to 'with'.
If this PEP is approved, the following PEPs will be rejected due
to overlap:
- PEP 288, Generators Attributes and Exceptions. The current PEP
covers its second half, generator exceptions (in fact the
throw() method name was taken from this PEP). I'm not in favor
of generator attributes, since they can easily be handled by
making the generator a method or by passing a mutable argument.
- PEP 310, Reliable Acquisition/Release Pairs. This is the
original with-statement proposal.
- PEP 325, Resource-Release Support for Generators. The current
PEP covers this (in fact the close() method name was taken from
this PEP).
- PEP 319, Python Synchronize/Asynchronize Block. Its use cases
can be covered by the current PEP by providing suitable
with-statement controllers: for 'synchronize' we can use the
"locking" template from example 1; for 'asynchronize' we can use
a similar "unlocking" template. I don't think having an
"anonymous" lock associated with a code block is all that
important; in fact it may be better to always be explicit about
the mutex being used.
(PEP 340 and PEP 346 have already been withdrawn.)
Motivation and Summary
PEP 340, Anonymous Block Statements, combined many powerful ideas:
@ -413,6 +440,10 @@ Examples
# guaranteed to be released when the block is left (even
# if via return or by an uncaught exception).
PEP 319 gives a use case for also having an unlocking()
template; this can be written very similarly (just swap the
acquire() and release() calls).
2. A template for opening a file that ensures the file is closed
when the block is left: