Mailman 3 May 2005 - Python-Dev

PEP 344: Exception Chaining and Embedded Tracebacks
by Ka-Ping Yee May 20, 2005

May 20, 2005

This PEP is a concrete proposal for exception chaining, to follow up on its mention here on Python-Dev last week as well as earlier discussions in the past year or two. http://www.python.org/peps/pep-0344.html I've tried to summarize the applications for chaining mentioned in these discussions, survey what's available in other languages, and come up with a precise specification. PEP 344 proposes three standard attributes on traceback objects: __context__ for implicit chaining (an unexpected exception occurred during 'except' or 'finally' processing) __cause__ for explicit chaining (intentional translation or augmenting of exceptions, set by "raise EXC from CAUSE") __traceback__ to point to the traceback Hope this is useful. I'd like your feedback. Thanks! -- Ping

11 24

python-dev Summary for 2005-05-01 through 2005-05-15 [draft]
by Tim Lesher May 20, 2005

May 20, 2005

Here's the first draft of the python-dev summary for the first half of May. Please send any corrections or suggestions to the summarizers (CC'ed). ====================== Summary Announcements ====================== ---------------------------------------------- PEP 340 Episode 2: Revenge of the With (Block) ---------------------------------------------- This fortnight's Python-Dev was dominated again by another nearly 400 messages on the topic of anonymous block statements. The discussion was a little more focused than the last thanks mainly to Guido's introduction of `PEP 340`_. Discussion of this PEP resulted in a series of other PEPs, including * `PEP 342`_: Enhanced Iterators, which broke out into a separate PEP the parts of `PEP 340`_ that allowed code to pass values into iterators using ``continue EXPR`` and yield-expressions. * `PEP 343`_: Anonymous Block Redux, a dramatically simplified version of `PEP 340`_, which removed the looping nature of the anonymous blocks and the injection-of-exceptions semantics for generators. * `PEP 3XX`_: User Defined ("with") Statements, which proposed non-looping anonymous blocks accompanied by finalization semantics for iterators and generators in for loops. Various details of each of these proposals are discussed below in the sections: 1. `Enhanced Iterators`_ 2. `Separate APIs for Iterators and Anonymous Blocks`_ 3. `Looping Anonymous Blocks`_ 4. `Loop Finalization`_ At the time of this writing, it looked like the discussion was coming very close to a final agreement; `PEP 343`_ and `PEP 3XX`_ both agreed upon the same semantics for the block-statement, the keyword had been narrowed down to either ``do`` or ``with``, and Guido had agreed to add back in to `PEP 343`_ some form of exception-injection semantics for generators. .. _PEP 340: http://www.python.org/peps/pep-0340.html .. _PEP 342: http://www.python.org/peps/pep-0342.html .. _PEP 343: http://www.python.org/peps/pep-0343.html .. _PEP 3XX: http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html<http://members.iinet.net.au/%7Encoghlan/public/pep-3XX.html> [SJB] ========= Summaries ========= ------------------ Enhanced Iterators ------------------ `PEP 340`_ incorporated a variety of orthogonal features into a single proposal. To make the PEP somewhat less monolithic, the method for passing values into an iterator was broken off into `PEP 342`_. This method includes: * updating the iterator protocol to use .__next__() instead of .next() * introducing a new builtin next() * allowing continue-statements to pass values into iterators * allowing generators to receive values with a yield-expression Though these features had seemed mostly uncontroversial, Guido seemed inclined to wait for a little more motivation from the co-routiney people before accepting the proposal. Contributing threads: - `Breaking off Enhanced Iterators PEP from PEP 340 < http://mail.python.org/pipermail/python-dev/2005-May/053463.html>`__ [SJB] ------------------------------------------------ Separate APIs for Iterators and Anonymous Blocks ------------------------------------------------ `PEP 340`_ had originally proposed to treat the anonymous block protocol as an extension of the iterator protocol. Several problems with this approach were raised, including: * for-loops could accidentally be used with objects requiring blocks, meaning that resources would not get cleaned up properly * blocks could be used instead of for-loops, violating TOOWTDI As a result, both `PEP 343`_ and `PEP 3XX`_ propose decorators for generator functions that will wrap the generator object appropriately to match the anonymous block protocol. Generator objects without the proposed decorators would not be usable in anonymous block statements. Contributing threads: - `PEP 340 -- loose ends < http://mail.python.org/pipermail/python-dev/2005-May/053206.html>`__ - `PEP 340 -- concept clarification < http://mail.python.org/pipermail/python-dev/2005-May/053280.html>`__ [SJB] ------------------------ Looping Anonymous Blocks ------------------------ A few issues arose as a result of `PEP 340`_'s formulation of anonymous blocks as a variation on a loop. Because the anonymous blocks of `PEP 340`_ were defined in terms of while-loops, there was some discussion as to whether they should have an ``else`` clause like Python ``for`` and ``while`` loops do. There didn't seem to be one obvious interpretation of an ``else`` block though, so Guido rejected the ``else`` block proposal. The big issue with looping anonymous blocks, however, was in the handling of ``break`` and ``continue`` statements. Many use cases for anonymous blocks did not require loops. However, because `PEP 340`_ anonymous blocks were implemented in terms of loops, ``break`` and ``continue`` acted much like they would in a loop. This meant that in code like:: for item in items: with lock: if handle(item): break the ``break`` statement would only break out of the anonymous block (the ``with`` statement) instead of breaking out of the for-loop. This pretty much shot-down `PEP 340`_; there were too many cases where an anonymous block didn't look like a loop, and having it behave like one would have been a major stumbling block in learning the construct. As a result, both `PEP 343`_ and `PEP 3XX`_ were proposed as non-looping versions of `PEP 340`_. Contributing threads: - `PEP 340: Else clause for block statements < http://mail.python.org/pipermail/python-dev/2005-May/053190.html>`__ - `PEP 340 -- loose ends < http://mail.python.org/pipermail/python-dev/2005-May/053206.html>`__ - `PEP 340 -- concept clarification < http://mail.python.org/pipermail/python-dev/2005-May/053226.html>`__ - `PEP 340: Breaking out. < http://mail.python.org/pipermail/python-dev/2005-May/053223.html>`__ - `PEP 340: Non-looping version (aka PEP 310 redux) < http://mail.python.org/pipermail/python-dev/2005-May/053400.html>`__ - `PEP 340 - Remaining issues < http://mail.python.org/pipermail/python-dev/2005-May/053406.html>`__ - `PEP 340: Deterministic Finalisation (new PEP draft, either a competitor or update to PEP 340) < http://mail.python.org/pipermail/python-dev/2005-May/053503.html>`__ - `Merging PEP 310 and PEP 340-redux? < http://mail.python.org/pipermail/python-dev/2005-May/053591.html>`__ - `PEP 343 - Abstract Block Redux < http://mail.python.org/pipermail/python-dev/2005-May/053731.html>`__ [SJB] ----------------- Loop Finalization ----------------- Greg Ewing pointed out that a generator with a yield inside a block-statement would require additional work to guarantee its finalization. For example, if the generator:: def all_lines(filenames): for name in filenames: with open(name) as f: for line in f: yield line were used in code like:: for line in all_lines(filenames): if some_cond(line): break then unless the for-loop performed some sort of finalization on the all_lines generator, the last-opened file could remain open indefinitiely. As a result, `PEP 3XX`_ proposes that for-loops check for a __finish__() method on their iterators, and if one exists, call that method when the for-loop completes. Generators like all_lines above, that put a yield inside a block-statement, would then acquire a __finish__() method that would raise a TerminateIteration exception at the point of the last yield. The TerminateIteration exception would thus cause the block-statement to complete, guaranteeing that the generator was properly finalized. Contributing threads: - `PEP 340 - For loop cleanup, and feature separation < http://mail.python.org/pipermail/python-dev/2005-May/053432.html>`__ - `PEP 340: Deterministic Finalisation (new PEP draft, either a competitor or update to PEP 340) < http://mail.python.org/pipermail/python-dev/2005-May/053503.html>`__ - `PEP 343 - Abstract Block Redux < http://mail.python.org/pipermail/python-dev/2005-May/053731.html>`__ [SJB] ---------------------------- Breaking out of Nested Loops ---------------------------- As a result of some of the issues of looping anonymous blocks, a few threads discussed options for breaking out of nested loops. These mainly worked by augmenting the ``break`` statement with another keyword (or keywords) that would indicate which loop to break out of. One proposal suggested that ``break`` be followed with ``for`` or ``while`` to indicate which loop to break out of. But ``break for`` would only really be useful in a while-loop nested within a for-loop, and ``break while`` would only really be useful in a for-loop nested within a while-loop. That is, because loops could only be named by type, the proposal was only useful when loops of different types were mixed. This suggestion was thus discarded as not being general enough. A few other suggestions were briefly discussed: adding labels to loops, using an integer to indicate which "stack level" to break at, and pushing breaks onto a "break buffer", but Guido killed the discussion, saying, `"Stop all discussion of breaking out of multiple loops. It ain't gonna happen before my retirement." <http://mail.python.org/pipermail/python-dev/2005-May/053592.html>`__ Contributing threads: - `PEP 340: Breaking out. < http://mail.python.org/pipermail/python-dev/2005-May/053223.html>`__ - `PEP 340: Deterministic Finalisation (new PEP draft, either a competitor or update to PEP 340) < http://mail.python.org/pipermail/python-dev/2005-May/053503.html>`__ [SJB] ------------------------ The future of exceptions ------------------------ Ka-Ping Yee suggested that instead of passing (type, value, traceback) tuples in exceptions it would be better to put the traceback in value.traceback. Guido had also suggested this (in the `PEP 340`_ murk) but pointed out that this would not work as long as string exceptions exist (as there is nowhere to put the traceback). Guido noted that there are no concrete plans as to when string exceptions will be deprecated and removed (other than in 3.0 at the latest); he indicated that it could be sooner, if someone wrote a PEP with a timeline (e.g. deprecated in 2.5, gone in 2.6). Brett C. volunteered to write a PEP targetted at Python 3000 covering exception changes (base inheritance, standard attributes (e.g. .traceback), reworking the built-in exception inheritance hierarchy, and the future of bare except statements). Contributing threads: - `Tidier Exceptions < http://mail.python.org/pipermail/python-dev/2005-May/053671.html>`__ .. _PEP 340: http://www.python.org/peps/pep-0340.html [TAM] ----------------------------------- Unifying try/except and try/finally ----------------------------------- Reinhold Birkenfeld submitted a Pre-PEP to allow both except and finally clauses in try blocks. For example, a construction like:: try: <suite 1> except Ex1: <suite 2> <more except: clauses> else: <suite 3> finally: <suite 4> would be exactly the same as the legacy:: try: try: <suite 1> except Ex1: <suite 2> <more except: clauses> else: <suite 3> finally: <suite 4> Guido liked this idea (so much that he wanted to accept it immediately), and recommended that it was checked in as a PEP. However, Tim Peters pointed out that this functionality was removed from Python (by Guido) way back in 0.9.6, seemingly because there was confusion about exactly when the finally clause would be called (explicit is better than implicit!). Guido clarified that control would only pass forward, and indicated that he felt that since this is now available in Java (and C#) fewer people would be confused. The main concern about this change was that, while the cost was low, it seemed to add very little value. Contributing threads: - `Pre-PEP: Unifying try-except and try-finally < http://mail.python.org/pipermail/python-dev/2005-May/053290.html>`__ [TAM] ----------------- Decorator Library ----------------- Michele Simionato asked whether a module for commonly used decorators, or utilities to create decorators, was planned. Raymond Hettinger indicated that while this was likely in the long term, he felt that it was better if these first evolved via wikis, recipes, or mailing lists, so that a module would only be added once best practices and proven winners had emerged. In the meantime, there is both a `Decorator Library wiki page`_ and you can try out `Michele's library`_ [zip]. To assist with decorator creation, Michele would like a facility to copy a function. Phillip J. Eby noted that the informally-discussed proposal is to add a mutable __signature__ to functions to assist with signature preserving decorators. Raymond suggested a patch adding a __copy__ method to functions or a patch for the copy module, and Michele indicated that he would also like to subclass FunctionType with an user-defined __copy__ method. Contributing threads: - `my first post: asking about a "decorator" module < http://mail.python.org/pipermail/python-dev/2005-May/053316.html>`__ - `The decorator module < http://mail.python.org/pipermail/python-dev/2005-May/053446.html>`__ .. _Decorator Library wiki page: http://www.python.org/moin/PythonDecoratorLibrary .. _Michele's library: http://www.phyast.pitt.edu/~micheles/python/decorator.zip<http://www.phyast.pitt.edu/%7Emicheles/python/decorator.zip> [TAM] --------------------- Hooking Py_FatalError --------------------- Errors that invoke Py_FatalError generally signify that the internal state of Python is in such a poor state that continuing (including raising an exception) is impossible or unwise; as a result, Py_FatalError outputs the error to stderr and calls abort(). m.u.k. would like to have a callback to hook Py_FatalError to avoid this call to abort(). The general consensus was that effort would be better directed to fixing the causes of fatal errors than hooking Py_FatalError. m.u.k.'s use case was for generating additional logging information; a `callback system patch`_ (revised by James William Pye) is available for those interested. Contributing threads: - `Need to hook Py_FatalError < http://mail.python.org/pipermail/python-dev/2005-May/053218.html>`__ .. _callback system patch: http://python.org/sf/1195571 ------------------- Chaining Exceptions ------------------- Ka-Ping Yee suggested adding information to exceptions when they are raised in the handler for another exception. For example:: def a(): try: raise AError except: raise BError raises an exception which is an instance of BError. This instance could have an attribute which is instance of AError, containing information about the original exception. Use cases include catching a low-level exception (e.g. socket.error) and turning it into a high-level exception (e.g. an HTTPRequestFailed exception) and handling problems in exception handling code. Guido liked the idea, and discussion fleshed out a tighter definition; however it was unclear whether adding this now was feasible - this would perhaps be best added in Python 3000. Contributing threads: - `Chained Exceptions < http://mail.python.org/pipermail/python-dev/2005-May/053672.html>`__ [TAM] ------------------ Py_UNICODE madness ------------------ Nicholas Bastin noted an apparent bug in the documentation for Py_UNICODE, which states that Py_UNICODE is 16-bit value implemented as an alias for wchar_t when that type is available, and for unsigned short otherwise However, on recent Redhat releases, PY_UNICODE_SIZE turns out to be 4. Guido and Marc-Andres Lemburg both agreed that the documentation is incorrect, so Nicholas set out to fix the documentation by removing the 16-bit reference and adding a caveat for extension developers not to make assumptions about the size of Py_UNICODE. It wasn't *quite* that simple. A long discussion ensued over why Python sometimes needs to default to UCS-4 Unicode (to avoid breaking an existing UCS-4 Tkinter), whether to expose the size of Py_UNICODE to extension developers (they won't take 'no' for an answer), and whether Python should provide better support for high surrogate pairs (it should). The matter remained open. Contributing threads: - `Py_UNICODE madness < http://mail.python.org/pipermail/python-dev/2005-May/053264.html>`__ - `New Py_UNICODE doc < http://mail.python.org/pipermail/python-dev/2005-May/053311.html>`__ - `New Py_UNICODE doc (Another Attempt) < http://mail.python.org/pipermail/python-dev/2005-May/053480.html>`__ [TDL] ------------------------------ Python's Unicode width default ------------------------------ Marc-Andre Lemburg objected to Python's build process automatically changing its default Unicode size from UCS2 to UCS4 at build time when a UCS4 version of Tcl is found. Martin Löwis argued that having Tkinter always work out of the box was more important than having a hard-and-fast Unicode default configuration; Marc dissented. Shane Hathaway opined that it could be a runtime rather than a compile-time decision, and Bob Ippolito mentioned NSString from OpenDarwin's libFoundation and CFString from Apple's CoreFoundation libraries for implementation ideas. Contributing threads: - `Python's Unicode width default (New Py_UNICODE doc) < http://mail.python.org/pipermail/python-dev/2005-May/053574.html>`__ [TDL] =============== Skipped Threads =============== - `Keyword for block statements < http://mail.python.org/pipermail/python-dev/2005-May/053189.html>`__ - `PEP 340 - possible new name for block-statement < http://mail.python.org/pipermail/python-dev/2005-May/053195.html>`__ - `Generating nested data structures with blocks < http://mail.python.org/pipermail/python-dev/2005-May/053204.html>`__ - `PEP 340 -- Clayton's keyword? < http://mail.python.org/pipermail/python-dev/2005-May/053377.html>`__ - `PEP 340: Only for try/finally? < http://mail.python.org/pipermail/python-dev/2005-May/053258.html>`__ - `2 words keyword for block < http://mail.python.org/pipermail/python-dev/2005-May/053251.html>`__ - `anonymous blocks < http://mail.python.org/pipermail/python-dev/2005-May/053297.html>`__ - `"begin" as keyword for pep 340 < http://mail.python.org/pipermail/python-dev/2005-May/053315.html>`__ - `PEP 340: propose to get rid of 'as' keyword < http://mail.python.org/pipermail/python-dev/2005-May/053320.html>`__ - `PEP 340 keyword: after < http://mail.python.org/pipermail/python-dev/2005-May/053396.html>`__ - `PEP 340 keyword: Extended while syntax < http://mail.python.org/pipermail/python-dev/2005-May/053409.html>`__ - `PEP 340 - Remaining issues - keyword < http://mail.python.org/pipermail/python-dev/2005-May/053428.html>`__ - `PEP 340: Examples as class's. < http://mail.python.org/pipermail/python-dev/2005-May/053423.html>`__ - `Proposed alternative to __next__ and __exit__ < http://mail.python.org/pipermail/python-dev/2005-May/053514.html>`__ - `"with" use case: exception chaining < http://mail.python.org/pipermail/python-dev/2005-May/053665.html>`__ - `PEP 343: Resource Composition and Idempotent __exit__ < http://mail.python.org/pipermail/python-dev/2005-May/053767.html>`__ - `[Python-checkins] python/nondist/peps pep-0343.txt, 1.8, 1.9 < http://mail.python.org/pipermail/python-dev/2005-May/053766.html>`__ - `the current behavior of try: ... finally: < http://mail.python.org/pipermail/python-dev/2005-May/053692.html>`__ - `a patch to inspect and a non-feature request < http://mail.python.org/pipermail/python-dev/2005-May/053653.html>`__ - `Python 2.4 set objects and cyclic garbage < http://mail.python.org/pipermail/python-dev/2005-May/053630.html>`__ - `CHANGE BayPIGgies: May *THIRD* Thurs < http://mail.python.org/pipermail/python-dev/2005-May/053628.html>`__ - `Python continually calling sigprocmask() on FreeBSD 5 < http://mail.python.org/pipermail/python-dev/2005-May/053615.html>`__ - `Weekly Python Patch/Bug Summary < http://mail.python.org/pipermail/python-dev/2005-May/053213.html>`__ - `problems with memory management < http://mail.python.org/pipermail/python-dev/2005-May/053408.html>`__ - `Adding DBL_MANTISSA and such to Python < http://mail.python.org/pipermail/python-dev/2005-May/053372.html>`__ - `python-dev Summary for 2005-04-16 through 2005-04-30 [draft] < http://mail.python.org/pipermail/python-dev/2005-May/053383.html>`__ - `Python Language track at Europython, still possibilities to submit talks <http://mail.python.org/pipermail/python-dev/2005-May/053303.html>`__ - `(no subject) < http://mail.python.org/pipermail/python-dev/2005-May/053196.html>`__ - `Kernel panic writing to /dev/dsp with cmpci driver < http://mail.python.org/pipermail/python-dev/2005-May/053627.html>`__ -- Tim Lesher <tlesher(a)gmail.com>

2 1

Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup
by Guido van Rossum May 19, 2005

May 19, 2005

I believe that in the discussion about PEP 343 vs. Nick's PEP 3XX (http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html, still awaiting PEP moderator approval I believe?) the main difference is that Nick proposes a way to inject an exception into a generator; and I've said a few times that I like that idea. I'd like to propose to make that a separate PEP, which can combine elements of PEP 288 and PEP 325. Summary: - g.throw(type, value, traceback) causes the specified exception to be thrown at the place where the generator g is currently suspended. If the generator catches the exception and yields another value, that is the return value of g.throw(). If it doesn't catch the exception, the throw() appears to raise the same exception passed it (it "falls through"). If the generator raises another exception (this includes the StopIteration produced when it returns) that exception is raised by the throw. In summary, throw() behaves like next() except it raises an exception at the place of the yield. If the generator is already in the closed state, throw() just raises the exception it was passed without going through the generator. - There's a new exception, GeneratorExit, which can be thrown to cause a generator to clean up. A generator should not yield a value in response to this exception. - g.close() throws a GeneratorExit exception in the generator, and catches it (so g.close() itself does not raise an exception). g.close() is idempotent -- if the generator is already closed, it is a no-op. If the generator, against the rules, yields another value, it is nevertheless marked closed. - When a generator is GC'ed, its close() method is called (which is a no-op if it is already closed). That's it! With this, we can write the decorator from Nick's PEP 3XX and the generator examples in PEP 343 can be rewritten to have a try/finally clause around the yield statement. Oh, somewhere it should be stated that yield without an expression is equivalent to yield None. PEP 342 ("continue EXPR") already implies that, so we don't have to write a separate PEP for it. I also propose to go with the alternative in PEP 342 of using next() rather than __next__() -- generators will have methods next(), throw(), and close(). -- --Guido van Rossum (home page: http://www.python.org/~guido/)

10 31

Fwd: Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup
by Guido van Rossum May 19, 2005

May 19, 2005

Here's the word on GC vs. __del__, by the way. ---------- Forwarded message ---------- From: Tim Peters <tim.peters(a)gmail.com> Date: May 19, 2005 10:24 AM Subject: Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup To: guido(a)python.org > Remind me. Why again is GC afraid to touch objects with a __del__? > (There's a good reason, it's so subtle I keep forgetting it and I > can't seem to reconstruct the argument from first principles this > morning.) tp_clear is called on the objects in a cycle in an arbitrary order, and it's possible for a __del__ method to (e.g.) resurrect any object in the cycle. But obj.tp_clear() doesn't necessarily leave obj in a sane state, so we could end up resurrecting insane objects. > Would the same reasoning apply to a generator that's part of a cycle if > deleting the generator would cause more Python code to run? The general rule now is that gc must guarantee that no object it decided is trash can be reachable from any Python code by the time a gc pass first calls tp_clear. Calling tp_clear can certainly trigger __del__ methods (and weakref callbacks), so it's not (a common misunderstanding) the rule that __del__ methods can't run at all during gc. The real rule is subtler than that: gc is happy to run a __del__ method (or wr callback), provided that no trash is reachable from such a method. I haven't had the bandwidth to follow this discussion, but I sure _suppose_ that other trash objects could be reachable from a trash generator in a cycle. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

PEP 343 - Abstract Block Redux
by Guido van Rossum May 19, 2005

May 19, 2005

I've written up the specs for my "PEP 340 redux" proposal as a separate PEP, PEP 343. http://python.org/peps/pep-0343.html Those who have been following the thread "Merging PEP 310 and PEP 340-redux?" will recognize my proposal in that thread, which received mostly positive responses there. Please review and ask for clarifications of anything that's unclear. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

17 74

Re: [Python-Dev] Simpler finalization semantics (was Re: PEP 343 - Abstract Block Redux)
by Michael Chermside May 19, 2005

May 19, 2005

Guido writes: [a rather silly objection to Phillip's proposal that 'with x:' is a no-op when x lacks __enter__ and __exit__] > I know this is not a very strong argument, but my gut tells me this > generalization of the with-statement is wrong, so I'll stick to it > regardless of the strength of the argument. The real reason will come > to me. Perhaps the real reason is that it allows errors to pass silently. If I write with foo: BLOCK where I should have written with locked(foo): BLOCK ...it silently "succeeds" by doing nothing. I CLEARLY intended to do the appropriate cleanup (or locking, or whatever), but it doesn't happen. -- Michael Chermside

2 1

Re: [Python-Dev] Simpler finalization semantics (was Re: PEP 343 -Abstract Block Redux)
by Michael Chermside May 18, 2005

May 18, 2005

[I apologize in advance if this sounds a bit disjointed... I started to argue one thing, but by the end had convinced myself of the opposite, and I re-wrote the email to match my final conclusion.] Guido writes: > About deleting VAR I have mixed feelings. [...] > I think that, given that we let the for-loop variable survive, we > should treat the with-statement variable the same way. We said the same thing about the variable in list comprehensions and it's now obvious that it should NEVER have been allowed to escape it's scope. But the key difference is that list comprehensions are EXPRESSIONS, and for and 'with' are STATEMENTS. Expressions shouldn't modify the local environment, statements often do. Of course, that argument _permits_ not deleting VAR, but doesn't recomend in favor of it. My first thought for ideal behavior was that if VAR was previously defined (eg: a global, an existing attribute of some object, etc), then it should not be 'del''ed afterward. But VAR was newly created by the 'with' statement then we WOULD del it to keep the namespace "neat". Trouble is, that's FAR too complex, and depends on a distinction Python has not used before (although it's nearly the same as the property that controls the meaning of globally declared variables). My next thought was to just allow 'with' statements to introduce their own "scope"... the meaning that the VAR variable takes on within a 'with' statement is not propogated outside the scope of the statement. But imagine trying to implement this in CPython... don't forget details like supporting locals(). If it's too hard to do, then it's probably not the right solution. So then I thought "Well, what's the harm in letting the variable survive the 'with' statement?" I'm a big fan of keeping namespaces "clean", but it's just not important enough to incurr other penalties. So in this case, I (reluctantly, after giving myself quite a talking-to) favor having the 'with' statement with VAR create said variable in the appropriate scope as a side-effect, much like 'for'. -- Michael Chermside

1 0

Re: [Python-Dev] Example for PEP 343
by Michael Chermside May 18, 2005

May 18, 2005

Phillip writes: > >@do_template > >def with_extra_precision(places=2): > > "Performs nested computation with extra digits of precision." > > decimal.getcontext().prec += 2 > > yield None > > decimal.getcontext().prec -= 2 > > Won't this do the wrong thing if something within the block alters > the precision? Depends on what behavior you want. I wrote it this way partly because that's how the example in the manual was written, and partly because I was thinking "if someone increased the precision by 3 within the block, then we probably want to leave it increased by 3 on block exit". On careful re-consideration, I think it'd be better to require that the block NOT make unbalanced changes to the precision... we could verify it using an assert statement. I avoided caching the context and restoring it, because I WANTED to allow code in the block to make OTHER alterations to the context and not clobber them after the block exits (eg: setting or clearing some trap). It's debatable whether that was a good design choice... there's a great deal of elegence to Guido's version used like this: Guido: > do with_decimal_context() as ctx: > ctx.prec += 2 > # change other settings > # algorithm goes here However, all of these are minor details compared to the bug that Raymond points out: Raymond: > The final "return +s" should be unindented. It should > be at the same level as the "do with_extra_precision()". The purpose of > the "+s" is to force the result to be rounded back to the *original* > precision. In effect, the "with_extra_precision" wrapper causes the calculations to be done with higher precision, AND causes any variables set during the block will retain their higher precision. (It's because context controls OPERATIONS but changing context never affects individual Decimal OBJECTS.) So I fear that the whole with_extra_precision() idea is just likely to tempt people into introducing subtle bugs, and it should probably be scrapped anyhow. Guido's approach to save-and- restore context works fine. -- Michael Chermside (PS: Another reason that I avoided a basic save-and-restore is that we have plenty of examples already of 'do' statements that save-and-restore, I was trying to do something different. It's interesting that what I tried may have turned out to be a poor idea.)

1 0

Re: [Python-Dev] Request for dev permissions
by Robert Brewer May 18, 2005

May 18, 2005

Reinhold Birkenfeld wrote: > would anybody mind if I was given permissions on the tracker > and CVS, for fixing small > things like bug #1202475. I feel that I can help you others > out a bit with this and > I promise I won't change the interpreter to accept braces... I made a patch for that one the next day, by the way. #1203094 Robert Brewer System Architect Amor Ministries fumanchu(a)amor.org P.S. Do you have a valid email address, RB? I wasn't able to fix up your nospam address by hand.

2 1

Re: [Python-Dev] Example for PEP 343
by Phillip J. Eby May 18, 2005

May 18, 2005

At 02:42 PM 5/17/2005 -0700, Michael Chermside wrote: ># ===== SAMPLE #1: increasing precision during a sub-calculation ===== > >import decimal > >@do_template >def with_extra_precision(places=2): > "Performs nested computation with extra digits of precision." > decimal.getcontext().prec += 2 > yield None > decimal.getcontext().prec -= 2 Won't this do the wrong thing if something within the block alters the precision?

5 12