[Python-Dev] Another PEP 343 contextmanager glitch

Guido van Rossum guido at python.org
Sat Mar 25 05:13:42 CET 2006


On 3/24/06, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 04:34 PM 3/24/2006 -0800, Guido van Rossum wrote:
> >You could probably tell the difference by comparing the exception it
> >raises to the exception you pass it.
>
> That's what I changed @contextmanager to do, because it's the only place
> where you have a good reason to re-raise (i.e., the generator re-raises in
> order to request propagation).
>
> Thus, this inspection code should only have to appear in one place:
> @contextmanager, rather than it having to be in every other context that
> needs to tell the difference.

Ah. After reading what you checked in I understand it better. The
issue is the slight impedance mismatch between throw() and __exit__():
throw() always has to re-raise the exception, because returning a
value already has a different meaning (the generator yielded again).
That's what I originally implemented for __exit__() after I realized
the need for a way to swallow exceptions, but then after reasonable
opposition that this would make writing a "vanilla" __exit__() a bit
tricky in a way that encourages buggy code, I changed it to returning
True to swallow the exception, and returning False *or* re-raising to
re-raise. (returning in any way also meant to continue a non-local
goto.)

I think that the code you added:

+            except:
+                if sys.exc_info()[1] is not value:
+                    raise

could use a comment explaining what's going on; the difference between
returning None and re-raising the exception is really quite subtle
here, and only ever matters if something else besides the
with-statement framework is calling __exit__. (I would add this
distinction to the PEP too.)

> By the way, I just got approval earlier this week to work on various Python
> 2.5 tasks as a "20% project" at OSAF, so today's my day this week to try to
> burn through as many outstanding Python 2.5 issues as possible.  Hence all
> my activity on PEPs 342 and 343.  My current rough plans for wsgiref,
> setuptools and the rest can be found at:
>
>      http://peak.telecommunity.com/DevCenter/Python25
>
> if anybody's interested.

Great news! I'm glad you're planning to finish up the PEP 302 stuff.

I'd like to see some discussion of your proposed change to .pth file
processing; this could cause some surprises and will slow down all
Python's start-up time due to the necessity to list every directory on
sys.path. This is IMO a bad thing; there must be nothing to keep
people from writing tiny scripts in Python, and slow startup time is
an inhibitor there. (If you don't believe this could be a problem, try
it with a long path containing several directories on NFS. This is the
standard setup of Google developer workstations, and it gives one a
different outlook on life.)

--
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-Dev mailing list