On 3/24/06, Phillip J. Eby <[EMAIL PROTECTED]> 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/) _______________________________________________ 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
