Re: [Python-Dev] PEP 343 - Abstract Block Redux
Phillip J. Eby wrote: > At 08:21 PM 5/16/2005 -0400, Jack Diederich wrote: > >>I still haven't gotten used to Guido's heart-attack inducing early >>enthusiasm for strange things followed later by a simple proclamation >>I like. Some day I'll learn that the sound of fingernails on the >>chalkboard is frequently followed by candy for the whole class. > > > Heh. +1 for QOTW. :) Indeed. Particularly since it sounds like son-of-PEP-343 will be the union of PEP 310 and PEP 340 that I've been trying to figure out :) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 - Abstract Block Redux
Guido van Rossum wrote: > [Greg Ewing] > >>I still think it's conceptually cleaner if the object >>you use to access the resource is created by the >>__enter__ method rather than being something pre- >>existing, but I'm willing to concede that PBP here. > > > PBP? Google finds "Python Browser Poseur" but no definition of IRC > slang. Proven Best Practice? Pakistani Border Patrol? Puffing Billy > Posse? Previously Belaboured Point? (Just guessing from context here, but if I'm right, that's one acronym I'm going to have to remember. . .) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 - Abstract Block Redux
Guido van Rossum wrote: > [Nick Coghlan] > >>That would be good, in my opinion. I updated PEP 3XX to use this idea: >>http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html >> >>With that update (to version 1.6), PEP 3XX is basically PEP 343, but injecting >>exceptions that occur into the template generator's internal frame instead of >>invoking next(). > > I'm in favor of the general idea, but would like to separate the error > injection and finalization API for generators into a separate PEP, > which would then compete with PEP 288 and PEP 325. Without that it pretty much devolves into the current version of PEP 343, though (as far as I can tell, the two PEP's now agree on the semantics of with statements) > I think the API > *should* be made public if it is available internally; I don't see any > implementation reasons why it would simplify the implementation if it > was only available internally. If it's internal, we don't need to name it immediately - working out the public API can then be decoupled from the ability to use generators to write resource managers. > Here are some issues to resolve in such a PEP. > > - What does _inject_exception() return? It seems that it should raise > the exception that was passed into it, but I can't find this written > out explicitly. That's a good point. The intent was for it to be equivalent to the exception being reraised at the point of the last yield. At that point, control flows like it would for a call to next() with code inside the generator that looked like: yield exc_type, value, tb = _passed_in_exception() raise exc_type, value, tb > - What should happen if a generator, in a finally or except clause > reached from _inject_exception(), executes another yield? I'm tempted > to make this a legitimate outcome (from the generator's perspective) > and reserve it for some future statement that implements the looping > semantics of PEP 340; the *_template decorator's wrapper class however > should consider it an error, just like other protocol mismatches like > not yielding the first time or yielding more than once in response to > next(). Nick's code in fact does all this right, Ijust think it should > be made explicit. Yep, that was the intent - you're correct that describing it in the text as well would make it clear that this is deliberate. > - TerminateIteration is a lousy name, since "terminate" means about > the same as "stop", so there could be legitimate confusion with > StopIteration. In PEP 340 I used StopIteration for this purpose, but > someone explained this was a poor choice since existing generators may > contain code that traps StopIteration for other purposes. Perhaps we > could use SystemExit for this purpose? Pretty much everybody is > supposed to let this one pass through since its purpose is only to > allow cleanup upon program (or thread) exit. Wouldn't that mean we run the risk of suppressing a *real* SystemExit if it occurs while a generator is being finalised? Perhaps a new exception IteratorExit, which is a subclass of SystemExit. Then well-behaved code wouldn't trap it accidentally, and the finalisation code wouldn't? > - I really don't like reusing __del__ as the method name for any kind > of destructor; __del__ has all sorts of special semantics (the GC > treats objects with a __del__ method specially). I guess if file objects can live without a __del__ method to automatically close, generators that require finalisation can survive without it. > - The all_lines() example jars me. Somehow it bugs me that its caller > has to remember to care about finalizing it. The alternative is to have some form of automatic finalisation in for loops, or else follow up on PJE's idea of making with statements allow pretty much *anything* to be used as VAR1. Automatic finalisation (like that now described in the Rejected Options section of my PEP) makes iterators/generators that manage resources 'just work' (nice) but complicates the semantics of generators (bad) and for loops (bad). The current version of my PEP means you need to know that a particular generator/iterator needs finalisation, and rearrange code to cope with that (bad), but keeps for loops simple (nice). PJE's idea about a permissive with statement may actually give the best of both worlds - you can *always* use the with statement, and if the supplied object doesn't need cleaning up, there's no more overhead than checking for the existence of methods in a couple of slots. (See my answer to Phillip on that topic for the gory details) > Maybe it's just not a > good example; I was having trouble thinking of a case where it made sense for the generator to manage its own resources. I agree all_lines isn't a great example, but its a safe bet that things like it will be written once the restriction on yielding inside try/finally is lifted. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia ---
[Python-Dev] Multiple interpreters not compatible with current thread module
The current threadmodule.c does not seem to correctly support multiple
(sub) interpreters.
This became apparent when using jep - (a Java/Python bridge) and also
seems to cause problems with mod_python.
The incompatibility began in Python version 2.3.5 and has been traced to changes
to the 2.4 threadmodule.c that were backported to the 2.3 delivery.
A bug report was raised on 2005-03-15
(http://sourceforge.net/tracker/index.php?func=detail&aid=1163563&group_id=5470&atid=105470)
which covers the problem in more detail.
I've just submitted a patch (I hope it's correctly formatted) for
threadmodule.c
(http://sourceforge.net/tracker/index.php?func=detail&aid=1203393&group_id=5470&atid=305470)
adapted from the pre-2.3.5 threadmodule.c (replacing the
PyGILState_XXX calls with those from the earlier thread module).
The patch works correctly but it will probably re-introduce the
problem that the change for threadmodule.c version 2.59 fixed.("Fix
for [ 1010677 ] thread Module Breaks PyGILState_Ensure(),and a test
case.When booting a new thread, use the PyGILState API to manage the
GIL.").
The documentation (http://docs.python.org/api/threads.html) states
"Note that the PyGILState_*() functions assume there is only one
global interpreter (created automatically by Py_Initialize()). Python
still supports the creation of additional interpreters (using
Py_NewInterpreter()), but mixing multiple interpreters and the
PyGILState_*() API is unsupported. ", so it looks like that using the
PyGilState_XXX functions in the core threadmodule.c means the
Py_NewInterpreter() call (i.e. multiple interpreters) is no longer
supported when threads are involved.
This problem is preventing us upgrading to Python 2.4 so we'd
obviously like to see a resolution the next Python release if that
were possible...
Cheers,
Max
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 - Abstract Block Redux
On 5/17/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > [Greg Ewing] > > > >>I still think it's conceptually cleaner if the object > >>you use to access the resource is created by the > >>__enter__ method rather than being something pre- > >>existing, but I'm willing to concede that PBP here. > > > > > > PBP? Google finds "Python Browser Poseur" but no definition of IRC > > slang. Proven Best Practice? Pakistani Border Patrol? Puffing Billy > > Posse? > > Previously Belaboured Point? (Just guessing from context here, but if I'm > right, > that's one acronym I'm going to have to remember. . .) Practicality Beats Purity, surely...? Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Simpler finalization semantics (was Re: PEP 343 - Abstract Block Redux)
Phillip J. Eby wrote: > I'm suggesting that we simply take Nick's proposal to its logical > conclusion, and allow any object to be usable under "with", since it > does not create any problems to do so. (At least, none that I can > see.) A redundant 'with' does no harm; in the worst case it's just a > hint to the reader about the scope within which an expression is used > within the current fuction body. Do you mean translating this: with EXPR1 as VAR1: BLOCK1 To something along the lines of: the_stmt = EXPR1 stmt_enter = getattr(the_stmt, "__enter__", None) stmt_exit = getattr(the_stmt, "__exit__", None) if stmt_enter is None: VAR1 = the_stmt else: VAR1 = stmt_enter() if stmt_exit is None: BLOCK1 else: exc = (None, None, None) try: try: BLOCK1 except: exc = sys.exc_info() raise finally: stmt_exit(*exc) It has a certain elegance - you can switch from using an object that needs finalisation to one that doesn't without having to change your code. And library code can safely ensure finalisation without having to check whether the object needs it or not - that check becomes an inherent part of the with statement. I'm ambivalent about this one - I see some benefit to it, but there's something niggling at the back of my brain that doesn't like it (nothing I can point to in particular, though). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 - Abstract Block Redux
Paul Moore wrote: > On 5/17/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: >>Previously Belaboured Point? (Just guessing from context here, but if I'm >>right, >> that's one acronym I'm going to have to remember. . .) > > Practicality Beats Purity, surely...? D'oh! *slaps forehead* Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 - Abstract Block Redux
Nick Coghlan wrote: > Wouldn't that mean we run the risk of suppressing a *real* SystemExit if it > occurs while a generator is being finalised? > > Perhaps a new exception IteratorExit, which is a subclass of SystemExit. Then > well-behaved code wouldn't trap it accidentally, and the finalisation code > wouldn't? ... inadvertently suppress a real SystemExit. Cheers, Nick. Must have been distracted halfway through that sentence :) -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 344: Exception Chaining and Embedded Tracebacks
On Mon, May 16, 2005, Guido van Rossum wrote: > > My rule has more to do with who "owns" the namespace on the one hand, > and with "magic" behavior caused (or indicated) by the presence of the > attribute on the other. Class or instance is irrelevant; that most > magic attributes live on classes or modules is just because those are > places where most of the magic is concentrated. > > __init__ in a class is a system attribute because it has a magic > meaning (invoked automatically on instantiation). __file__ and > __name__ in a module (and __module__ and __name__ in a class!) are > system attributes because they are "imposing" on the user's use of the > namespace. (Note: next was a mistake; it should have been __next__ > because of the "magic" rule.) >From my POV, part of the reasoning should be the extent to which the attribute is intended to be publicly accessible -- part of the primary documented interface. __init__ is magic, fine. But __name__ isn't part of the primary use for a class, whereas these new exception attributes will be part of the public interface for exceptions, just like the methods for the Queue class. (I'm using Queue in specific because it's intended to be subclassed.) -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "And if that makes me an elitist...I couldn't be happier." --JMS ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Simpler finalization semantics (was Re: PEP 343 - Abstract Block Redux)
[Nick Coghlan (replying to Phillip)] > Do you mean translating this: > >with EXPR1 as VAR1: >BLOCK1 > > To something along the lines of: > >the_stmt = EXPR1 >stmt_enter = getattr(the_stmt, "__enter__", None) >stmt_exit = getattr(the_stmt, "__exit__", None) > >if stmt_enter is None: >VAR1 = the_stmt >else: >VAR1 = stmt_enter() > >if stmt_exit is None: >BLOCK1 >else: >exc = (None, None, None) >try: >try: >BLOCK1 >except: >exc = sys.exc_info() >raise >finally: >stmt_exit(*exc) -1. The compiler must generate both code paths but one is wasted. 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. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 344: Exception Chaining and Embedded Tracebacks
[Guido van Rossum] > > My rule has more to do with who "owns" the namespace on the one hand, > > and with "magic" behavior caused (or indicated) by the presence of the > > attribute on the other. Class or instance is irrelevant; that most > > magic attributes live on classes or modules is just because those are > > places where most of the magic is concentrated. > > > > __init__ in a class is a system attribute because it has a magic > > meaning (invoked automatically on instantiation). __file__ and > > __name__ in a module (and __module__ and __name__ in a class!) are > > system attributes because they are "imposing" on the user's use of the > > namespace. (Note: next was a mistake; it should have been __next__ > > because of the "magic" rule.) [Aahz] > >From my POV, part of the reasoning should be the extent to which the > attribute is intended to be publicly accessible -- part of the primary > documented interface. __init__ is magic, fine. But __name__ isn't part > of the primary use for a class, whereas these new exception attributes > will be part of the public interface for exceptions, just like the > methods for the Queue class. (I'm using Queue in specific because it's > intended to be subclassed.) I dunno. Would you find __doc__ not part of the primary, documented interface of classes? Or __bases__? The Queue class is irrelevant because the VM doesn't know about it; *almost* all system atribute are referenced by the VM (or by the compiler) at some point(*). The reverse is not true, BTW -- many built-in objects (e.g. tracebacks, code and function objects) have non-system attributes. If this were Python 3000, I'd definitely make the traceback and cause non-system attributes. Given we're retrofitting, I'm less sure; surely some user-defined exceptions have cause and/or traceback attributes already. (*) I'd say metadata like __version__ is the exception; it's a system attribute because it's metadata, and because it lives in a crowded namespace, and because it was retrofitted as a convention. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 344: Exception Chaining and Embedded Tracebacks
I figured out the semantics that I'd like to see intuitively for setting the context. I'm not saying this is all that reasonable, but I'd like throw it out anyway to see what responses it gets. Consider try: BLOCK except EXCEPTION, VAR: HANDLER I'd like to see this translated into try: BLOCK except EXCEPTION, VAR: __context = VAR try: HANDLER except Exception, __error: __error.__context__ = __context raise i.e. the context is set only upon *leaving* the handler. (The translation for finally is hairier but you get the idea at this point.) My intuition prefers this over Ping's solution because HANDLER could easily invoke code that (after many stack levels deep) raises and catches many exceptions, and I'd hate to see all those be bothered by the context (far down on the stack) that is irrelevant. BTW, please study how the traceback is built up. I believe that if we store the traceback in the exception instance, we have to update the __traceback__ attribute each time we pop a stack level. IIRC that's how the traceback chain is built up. (The alternative, building the whole chain when the exception is raised, would be too expensive for exceptions raised *and* caught somewhere deep.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Simpler finalization semantics (was Re: PEP 343 - Abstract Block Redux)
At 11:03 PM 5/17/2005 +1000, Nick Coghlan wrote: >Do you mean translating this: > >with EXPR1 as VAR1: >BLOCK1 > >To something along the lines of: > >the_stmt = EXPR1 >stmt_enter = getattr(the_stmt, "__enter__", None) >stmt_exit = getattr(the_stmt, "__exit__", None) > >if stmt_enter is None: >VAR1 = the_stmt >else: >VAR1 = stmt_enter() > >if stmt_exit is None: >BLOCK1 >else: >exc = (None, None, None) >try: >try: >BLOCK1 >except: >exc = sys.exc_info() >raise >finally: >stmt_exit(*exc) Essentially, yes; although I was actually suggesting that there be PyResource_Enter() and PyResource_Exit() C APIs that would supply the default behaviors if the tp_resource_enter and tp_resource_exit slots were missing from the object's type. But that's an implementation detail. >It has a certain elegance - you can switch from using an object that needs >finalisation to one that doesn't without having to change your code. > >And library code can safely ensure finalisation without having to check >whether >the object needs it or not - that check becomes an inherent part of the with >statement. Precisely. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Simpler finalization semantics (was Re: PEP 343 - Abstract Block Redux)
At 07:17 AM 5/17/2005 -0700, Guido van Rossum wrote: >The compiler must generate both code paths but one is wasted. Not if the default behavior is encapsulated in PyResource_Enter() (returning the object if no __enter__) and PyResource_Exit() (a no-op if no __exit__). You're going to have to have the branch and test for slot presence *somewhere*. >I know this is not a very strong argument, It's not even an actual 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. I don't know about anybody else, but I'd prefer to hear that your gut tells you it's wrong, because that at least tells me there's no point in arguing. Pseudo-reasons just make me think there's something to discuss. :) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 344: Exception Chaining and Embedded Tracebacks
At 07:41 AM 5/17/2005 -0700, Guido van Rossum wrote: >Consider > > try: > BLOCK > except EXCEPTION, VAR: > HANDLER > >I'd like to see this translated into > > try: > BLOCK > except EXCEPTION, VAR: > __context = VAR > try: > HANDLER > except Exception, __error: > __error.__context__ = __context > raise > >i.e. the context is set only upon *leaving* the handler. (The >translation for finally is hairier but you get the idea at this >point.) > >My intuition prefers this over Ping's solution because HANDLER could >easily invoke code that (after many stack levels deep) raises and >catches many exceptions, and I'd hate to see all those be bothered by >the context (far down on the stack) that is irrelevant. This seems intuitively correct to me as well. If an error occurs in an error handler, you want the system to add the context for you. If you're writing a handler that creates a replacement exception, you don't have to manually wrap the current exception - the system will add it for you when the replacement exception leaves the handler. In both use cases, you want the new exception to be prominent, and the old exception is for digging deeper into the matter. Very nice. Hm. What about code like this (made-up) example, though? def __getattr__(self,attr): try: return self.__auxattrs[attr] except KeyError: raise AttributeError,attr Under this proposal, IIUC, you would get the context exception for the original KeyError, but it's "as designed". In order to get rid of the context traceback, you'd have to write: def __getattr__(self,attr): try: return self.__auxattrs[attr] except KeyError: pass raise AttributeError,attr Which isn't a big deal, but there's a lot of existing code that follows the first form, that would lead to a kind of "traceback spam". >BTW, please study how the traceback is built up. I believe that if we >store the traceback in the exception instance, we have to update the >__traceback__ attribute each time we pop a stack level. Yes; using .tb_next to build a linked list that goes "towards the exception frame". But at least the context exception doesn't need that, since the context traceback can reasonably end at the frame where it was caught. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 344: Exception Chaining and Embedded Tracebacks
Guido van Rossum wrote: > Consider > > try: > BLOCK > except EXCEPTION, VAR: > HANDLER > > I'd like to see this translated into > > try: > BLOCK > except EXCEPTION, VAR: > __context = VAR > try: > HANDLER > except Exception, __error: > __error.__context__ = __context > raise If I interpret the above translation correctly, then: try: BLOCK1 except EXCEPTION1, VAR1: try: BLOCK2 except EXCEPTION2, VAR2: HANDLER with exceptions occuring in BLOCK1, BLOCK2 and HANDLER would result in HANDLER's exception with __context__ set to BLOCK1's exception and BLOCK2's exception would be lost. --eric ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 344: Exception Chaining and Embedded Tracebacks
But that could easily be fixed by appending the context to the end of the chain, right? On 5/17/05, Eric Nieuwland <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > Consider > > > > try: > > BLOCK > > except EXCEPTION, VAR: > > HANDLER > > > > I'd like to see this translated into > > > > try: > > BLOCK > > except EXCEPTION, VAR: > > __context = VAR > > try: > > HANDLER > > except Exception, __error: > > __error.__context__ = __context > > raise > > If I interpret the above translation correctly, then: > try: > BLOCK1 > except EXCEPTION1, VAR1: > try: > BLOCK2 > except EXCEPTION2, VAR2: > HANDLER > > with exceptions occuring in BLOCK1, BLOCK2 and HANDLER would result in > HANDLER's exception with __context__ set to BLOCK1's exception and > BLOCK2's exception would be lost. > > --eric > > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 - Abstract Block Redux
[Guido van Rossum] > > I'm in favor of the general idea, but would like to separate the error > > injection and finalization API for generators into a separate PEP, > > which would then compete with PEP 288 and PEP 325. [Nick Coghlan] > Without that it pretty much devolves into the current version of PEP 343, > though > (as far as I can tell, the two PEP's now agree on the semantics of with > statements) But that's okay, right? We can just accept both PEPs and we're done. (And PEP 342 at the same time. :-) Discussing one PEP at a time is sometimes easier, even if they are meant to be used together. > > I think the API > > *should* be made public if it is available internally; I don't see any > > implementation reasons why it would simplify the implementation if it > > was only available internally. > > If it's internal, we don't need to name it immediately - working out the > public > API can then be decoupled from the ability to use generators to write resource > managers. That's a minor point -- it's not like generators have a namespace for the user that we don't want to pollute, so we can pick any name we like. > > Here are some issues to resolve in such a PEP. > > > > - What does _inject_exception() return? It seems that it should raise > > the exception that was passed into it, but I can't find this written > > out explicitly. > > That's a good point. The intent was for it to be equivalent to the exception > being reraised at the point of the last yield. At that point, control flows > like > it would for a call to next() with code inside the generator that looked like: > >yield >exc_type, value, tb = _passed_in_exception() >raise exc_type, value, tb So, also, _inject_exception() will appear to raise the exception that was passed to it, unless the generator catches it. > > - What should happen if a generator, in a finally or except clause > > reached from _inject_exception(), executes another yield? I'm tempted > > to make this a legitimate outcome (from the generator's perspective) > > and reserve it for some future statement that implements the looping > > semantics of PEP 340; the *_template decorator's wrapper class however > > should consider it an error, just like other protocol mismatches like > > not yielding the first time or yielding more than once in response to > > next(). Nick's code in fact does all this right, Ijust think it should > > be made explicit. > > Yep, that was the intent - you're correct that describing it in the text as > well > would make it clear that this is deliberate. OK. Please update the PEP then! > > - TerminateIteration is a lousy name, since "terminate" means about > > the same as "stop", so there could be legitimate confusion with > > StopIteration. In PEP 340 I used StopIteration for this purpose, but > > someone explained this was a poor choice since existing generators may > > contain code that traps StopIteration for other purposes. Perhaps we > > could use SystemExit for this purpose? Pretty much everybody is > > supposed to let this one pass through since its purpose is only to > > allow cleanup upon program (or thread) exit. > > Wouldn't that mean we run the risk of suppressing a *real* SystemExit if it > occurs while a generator is being finalised? D'oh. Yes. > Perhaps a new exception IteratorExit, which is a subclass of SystemExit. Then > well-behaved code wouldn't trap [SystemExit] accidentally, > and the finalisation code wouldn't? Nah, I think it needs to be a brand spanking new exception. It just can't be called TerminateIteration. How about GeneratorFinalization to be utterly clear? > > - I really don't like reusing __del__ as the method name for any kind > > of destructor; __del__ has all sorts of special semantics (the GC > > treats objects with a __del__ method specially). > > I guess if file objects can live without a __del__ method to automatically > close, generators that require finalisation can survive without it. Right. At the C level there is of course finalization (the tp_dealloc slot in the PyTypeObject struct) but it doesn't have a Python entry point to call it. And that's intentional, since the typical code executed by that slot *really* destroys the object and must only be called when the VM is absolutely sure that the object can't be reached in any other way. if it were callable from Python, that guarantee would be void. > > - The all_lines() example jars me. Somehow it bugs me that its caller > > has to remember to care about finalizing it. > > The alternative is to have some form of automatic finalisation in for loops, > or > else follow up on PJE's idea of making with statements allow pretty much > *anything* to be used as VAR1. > > Automatic finalisation (like that now described in the Rejected Options > section > of my PEP) makes iterators/generators that manage resources 'just work' (nice) > but complicates the semantics of generators (bad) and for loops (bad). > > The current version of
[Python-Dev] Example for PEP 343
In PEP 343 Guido writes: >8. Another use for this feature is the Decimal context. It's left > as an exercise for the reader. (Mail it to me if you'd like to > see it here.) Here are two such examples. Pick your favorite for the PEP. PS: Writing this helped convince me that allowing the use of generators instead of classes with the "do_template" decorator is quite nice in practice, even though it gets confusing (for beginners anyhow) if you start to think about it too much. -- Michael Chermside # = 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 # == SAMPLE USE of #1 == # (Sample taken from the Python Library Reference) def sin(x): "Return the sine of x as measured in radians." do with_extra_precision(): i, lasts, s, fact, num, sign = 1, 0, x, 1, x, 1 while s != lasts: lasts = s i += 2 fact *= i * (i-1) num *= x * x sign *= -1 s += num / fact * sign return +s # = SAMPLE #2: insisting on exact calculations only = import decimal @do_template def assert_exact(): "Raises exception if nested computation is not exact." ctx = decimal.getcontext() was_inexact = ctx.traps[decimal.Inexact] ctx.traps[decimal.Inexact] = True yield None ctx.traps[decimal.Inexact] = was_inexact # == SAMPLE USE of #2 == # Lemma 2 ensures us that each fraction will divide evenly do assert_exact(): total = decimal.Decimal(0) for n, d in zip(numerators, denominators): total += n / d ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Example for PEP 343
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? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Example for PEP 343
> -Original Message- > From: [EMAIL PROTECTED] [mailto:python-dev- > [EMAIL PROTECTED] On Behalf Of Phillip J. Eby > Sent: Tuesday, May 17, 2005 6:06 PM > To: Michael Chermside; [EMAIL PROTECTED] > Cc: [email protected] > Subject: Re: [Python-Dev] Example for PEP 343 > > 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? Right. It should save, alter, and then restore: oldprec = decimal.getcontext().prec decimal.getcontext().prec += 2 yield None decimal.getcontext().prec = oldprec Raymond Hettinger ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Example for PEP 343
What's the advantage of using two calls to getcontext() vs. saving the context in a local variable? On 5/17/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:python-dev- > > [EMAIL PROTECTED] On Behalf Of Phillip J. Eby > > Sent: Tuesday, May 17, 2005 6:06 PM > > To: Michael Chermside; [EMAIL PROTECTED] > > Cc: [email protected] > > Subject: Re: [Python-Dev] Example for PEP 343 > > > > 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? > > Right. > > It should save, alter, and then restore: > >oldprec = decimal.getcontext().prec >decimal.getcontext().prec += 2 >yield None >decimal.getcontext().prec = oldprec > > > Raymond Hettinger > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Example for PEP 343
> What's the advantage of using two calls to getcontext() vs. saving the > context in a local variable? I prefer saving the context in a local variable but that is just a micro-optimization. The presentation with multiple calls to getcontext() was kept just to match the style of the original -- the important change was the absolute save and restore versus the original relative adjust up and adjust down. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Simpler finalization semantics (was Re: PEP 343 - Abstract Block Redux)
Nick Coghlan wrote: >the_stmt = EXPR1 >stmt_enter = getattr(the_stmt, "__enter__", None) >stmt_exit = getattr(the_stmt, "__exit__", None) > >if stmt_enter is None: >VAR1 = the_stmt >else: >VAR1 = stmt_enter() If we're doing this, it might be better if VAR were simply bound to EXPR in all cases. Otherwise the ability to liberally sprinkle with-statements around will be hampered by uncertainty about what kind of object VAR will end up being. Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Simpler finalization semantics (was Re: PEP 343 - Abstract Block Redux)
And we're back at PEP 310 and you can't really write opening() as a generator. On 5/17/05, Greg Ewing <[EMAIL PROTECTED]> wrote: > Nick Coghlan wrote: > > >the_stmt = EXPR1 > >stmt_enter = getattr(the_stmt, "__enter__", None) > >stmt_exit = getattr(the_stmt, "__exit__", None) > > > >if stmt_enter is None: > >VAR1 = the_stmt > >else: > >VAR1 = stmt_enter() > > If we're doing this, it might be better if VAR were simply > bound to EXPR in all cases. Otherwise the ability to liberally > sprinkle with-statements around will be hampered by uncertainty > about what kind of object VAR will end up being. > > Greg > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Example for PEP 343
> > What's the advantage of using two calls to getcontext() vs. saving the > > context in a local variable? > > I also prefer saving the context in a local variable but that is just a > micro-optimization. The presentation with multiple calls to > getcontext() was kept just to match the style of the original -- the > important change was the absolute save and restore versus the original > relative adjust up and adjust down. One more thought: Rather than just saving the precision, it is likely wiser, safer, and more general to just save and restore the whole context and let the wrapped block only work with a copy. oldcontext = decimal.getcontext() newcontext = oldcontext.copy() newcontext.prec += 2 yield None decimal.setcontext(oldcontext) This approach defends against various kinds of unruly behavior by the yield target. Raymond Hettinger ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 344: Exception Chaining and Embedded Tracebacks
Guido van Rossum wrote: > Unfortunately I can't quite decide whether either rule applies in the > case of exceptions. I think you'd at least be justified in using the "magic" rule, since they're set by the exception machinery. Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Simpler finalization semantics (was Re: PEP 343 - Abstract Block Redux)
At 12:48 PM 5/18/2005 +1200, Greg Ewing wrote: >Nick Coghlan wrote: > > >the_stmt = EXPR1 > >stmt_enter = getattr(the_stmt, "__enter__", None) > >stmt_exit = getattr(the_stmt, "__exit__", None) > > > >if stmt_enter is None: > >VAR1 = the_stmt > >else: > >VAR1 = stmt_enter() > >If we're doing this, it might be better if VAR were simply >bound to EXPR in all cases. Otherwise the ability to liberally >sprinkle with-statements around will be hampered by uncertainty >about what kind of object VAR will end up being. It'll be whatever kind of object you should get when you're using EXPR as a resource. :) In other words, it looks like normal duck typing to me: what you get when you access something.quack() is whatever 'something' thinks you should get. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Example for PEP 343
On May 17, 2005, at 9:02 PM, Raymond Hettinger wrote: >>> What's the advantage of using two calls to getcontext() vs. saving >>> > the > >>> context in a local variable? >>> >> >> I also prefer saving the context in a local variable but that is just >> > a > >> micro-optimization. The presentation with multiple calls to >> getcontext() was kept just to match the style of the original -- the >> important change was the absolute save and restore versus the >> original >> relative adjust up and adjust down. >> > > One more thought: Rather than just saving the precision, it is likely > wiser, safer, and more general to just save and restore the whole > context and let the wrapped block only work with a copy. > > oldcontext = decimal.getcontext() > newcontext = oldcontext.copy() > newcontext.prec += 2 > yield None > decimal.setcontext(oldcontext) > > This approach defends against various kinds of unruly behavior by the > yield target. I think you're missing a decimal.setcontext(newcontext) before the yield.. -bob ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Example for PEP 343
Bob Ippolito wrote: >> One more thought: Rather than just saving the precision, it is >> likely wiser, safer, and more general to just save and restore the >> whole context and let the wrapped block only work with a copy. >> >> oldcontext = decimal.getcontext() >> newcontext = oldcontext.copy() >> newcontext.prec += 2 >> yield None >> decimal.setcontext(oldcontext) >> >> This approach defends against various kinds of unruly behavior by the >> yield target. > > I think you're missing a decimal.setcontext(newcontext) before the > yield.. Seems to me this should be in the standard library ;) Tim Delaney ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Example for PEP 343
> I think you're missing a decimal.setcontext(newcontext) before the > yield.. Right. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 - Abstract Block Redux
Nick Coghlan wrote: > Paul Moore wrote: > >>On 5/17/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: >> >>>Previously Belaboured Point? (Just guessing from context here, but if I'm >>>right, >>>that's one acronym I'm going to have to remember. . .) >> >>Practicality Beats Purity, surely...? > > > D'oh! *slaps forehead* > > Cheers, > Nick. > Hmmm... looks like Google needs a "Search Only in Python Terminology" radio button... Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Example for PEP 343
On 5/17/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > I think you're missing a decimal.setcontext(newcontext) before the > > yield.. > > Right. I don't see a call to setcontext() in the sin() example in the library reference. Is that document wrong? I thought that simply modifying the parameters of the current context would be sufficient. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Example for PEP 343
On May 17, 2005, at 10:36 PM, Guido van Rossum wrote: > On 5/17/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > >>> I think you're missing a decimal.setcontext(newcontext) before the >>> yield.. >>> >> >> Right. >> > > I don't see a call to setcontext() in the sin() example in the library > reference. Is that document wrong? I thought that simply modifying the > parameters of the current context would be sufficient. The library reference isn't modifying the parameters in a *copy* of the current context. -bob ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Example for PEP 343
> I don't see a call to setcontext() in the sin() example in the library > reference. Is that document wrong? I thought that simply modifying the > parameters of the current context would be sufficient. The sin() example is correct. The precision is changed and restored in the current context. However, for a general purpose wrapper, it is preferable to make a context copy and then restore the context after the enclosed is run. That guards against the enclosed block making any unexpected context changes. Also, since the wrapper is intended to work like a try/finally, it will make sure the context gets restored even if an exception is raised at some unexpected point in the middle of the computation. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Example for PEP 343
[Raymond Hettinger] > The sin() example is correct. The precision is changed and restored in > the current context. I got that eventually. :-) > However, for a general purpose wrapper, it is preferable to make a > context copy and then restore the context after the enclosed is run. > That guards against the enclosed block making any unexpected context > changes. (Although if people get in the habit of using the provided wrappers and the do-statement, there won't be any unexpected changes.) > Also, since the wrapper is intended to work like a try/finally, it will > make sure the context gets restored even if an exception is raised at > some unexpected point in the middle of the computation. Yes, that's the point of the do-statement. :- Anyway, perhaps we should provide this most general template: @do_template def with_decimal_context(): oldctx = decimal.getcontext() newctx = oldctx.copy() decimal.setcontext(newctx) yield newctx decimal.setcontext(oldctx) To be used like this: do with_decimal_context() as ctx: ctx.prec += 2 # change other settings # algorithm goes here -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Example for PEP 343
On May 17, 2005, at 11:39 PM, Guido van Rossum wrote: > [Raymond Hettinger] > >> However, for a general purpose wrapper, it is preferable to make a >> context copy and then restore the context after the enclosed is run. >> That guards against the enclosed block making any unexpected context >> changes. >> > > (Although if people get in the habit of using the provided wrappers > and the do-statement, there won't be any unexpected changes.) > > >> Also, since the wrapper is intended to work like a try/finally, it >> will >> make sure the context gets restored even if an exception is raised at >> some unexpected point in the middle of the computation. >> > > Yes, that's the point of the do-statement. :- > > Anyway, perhaps we should provide this most general template: > > @do_template > def with_decimal_context(): > oldctx = decimal.getcontext() > newctx = oldctx.copy() > decimal.setcontext(newctx) > yield newctx > decimal.setcontext(oldctx) > > To be used like this: > > do with_decimal_context() as ctx: > ctx.prec += 2 > # change other settings > # algorithm goes here I have yet to use the decimal module much, so I may be completely off here.. but why not write it like this: @do_template def with_decimal_context(): curctx = decimal.getcontext() oldctx = curctx.copy() yield curctx decimal.setcontext(oldctx) Saves a line and a context set :) -bob ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] python/nondist/peps pep-0343.txt, 1.11, 1.12
> +def sin(x):
> +"Return the sine of x as measured in radians."
> +do with_extra_precision():
> +i, lasts, s, fact, num, sign = 1, 0, x, 1, x, 1
> +while s != lasts:
> +lasts = s
> +i += 2
> +fact *= i * (i-1)
> +num *= x * x
> +sign *= -1
> +s += num / fact * sign
> +return +s
One more change: 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.
This nuance is likely to be the bane of folks who shift back and forth
between different levels of precision. The following example shows the
kind of oddity that can arise when working with quantities that have not
been rounded to the current precision:
>>> from decimal import getcontext, Decimal as D
>>> getcontext().prec = 3
>>> D('3.104') + D('2.104')
Decimal("5.21")
>>> D('3.104') + D('0.000') + D('2.104')
Decimal("5.20")
Raymond
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Weekly Python Patch/Bug Summary
Patch / Bug Summary
___
Patches : 339 open ( +7) / 2838 closed ( +4) / 3177 total (+11)
Bugs: 938 open (+11) / 4962 closed ( +3) / 5900 total (+14)
RFE : 187 open ( +1) / 157 closed ( +0) / 344 total ( +1)
New / Reopened Patches
__
Restore GC support to set objects (2005-05-11)
http://python.org/sf/1200018 opened by Barry A. Warsaw
idlelib patch (2005-05-11)
http://python.org/sf/1200038 opened by sowjanya
Small optimization for PyDict_Merge() (2005-05-11)
CLOSED http://python.org/sf/1200051 opened by Barry A. Warsaw
buffer overflow in _cursesmodule.c (2005-05-11)
http://python.org/sf/1200134 opened by Jan Michael Hülsbergen
patch IDLE to allow running anonymous code in editor window (2005-05-13)
http://python.org/sf/1201522 opened by Jeff Shute
allow running multiple instances of IDLE (2005-05-13)
http://python.org/sf/1201569 opened by Jeff Shute
httplib mentions getreply instead of getresponse (2005-05-16)
http://python.org/sf/1203094 opened by Robert Brewer
workaround deprecated ostat structure in (2005-05-17)
http://python.org/sf/1203329 opened by J. J. Snitow
Patch for [ 1163563 ] Sub threads execute in restricted mode (2005-05-17)
http://python.org/sf/1203393 opened by anothermax
Allow larger programs to be frozen under Win32 (2005-05-17)
http://python.org/sf/1203650 opened by Gottfried Ganßauge
Patches Closed
__
Small optimization for PyDict_Merge() (2005-05-11)
http://python.org/sf/1200051 closed by rhettinger
better datetime support for xmlrpclib (2005-02-10)
http://python.org/sf/1120353 closed by montanaro
Add O_SHLOCK/O_EXLOCK to posix (2005-01-17)
http://python.org/sf/1103951 closed by montanaro
Fix _tryorder in webbrowser.py (2005-03-20)
http://python.org/sf/1166780 closed by rodsenra
New / Reopened Bugs
___
installation problem with python 2.4.1 on Win2k system (2005-05-11)
http://python.org/sf/1199808 opened by mmkobayashi
Python 2.4.1 Installer ended prematurely (2005-05-11)
http://python.org/sf/1199947 opened by Wai Yip Tung
time module ignores timezone changes (2005-05-09)
CLOSED http://python.org/sf/1198275 reopened by bcannon
Windows msi installer fails on virtual drives (2005-05-11)
http://python.org/sf/1200287 opened by bartgrantham
SyntaxError raised on win32 for correct files (2005-05-12)
http://python.org/sf/1200686 opened by Federico Di Gregorio
Wrong word on "raise" page (2005-05-13)
CLOSED http://python.org/sf/1201438 opened by Erik Rose
Problem with recursion in dict (crash with core dump) (2005-05-13)
http://python.org/sf/1201456 opened by Vladimir Yu. Stepanov
suspected cPickle memory leak (2005-05-13)
http://python.org/sf/1201461 opened by Alan
Glossary listing bug (2005-05-14)
CLOSED http://python.org/sf/1201807 opened by George Yoshida
mimetypes.py does not find mime.types on Mac OS X (2005-05-14)
http://python.org/sf/1202018 opened by Stefan H. Holek
Description of string.lstrip() needs improvement (2005-05-15)
http://python.org/sf/1202395 opened by Roy Smith
httplib docs mentioning HTTPConnection.getreply (2005-05-15)
http://python.org/sf/1202475 opened by Georg Brandl
RE parser too loose with {m,n} construct (2005-05-15)
http://python.org/sf/1202493 opened by Skip Montanaro
a bunch of infinite C recursions (2005-05-15)
http://python.org/sf/1202533 opened by Armin Rigo
Problem with abs function (2005-05-16)
http://python.org/sf/1202946 opened by ric-b
Bugs Closed
___
time module ignores timezone changes (2005-05-09)
http://python.org/sf/1198275 closed by bcannon
SystemError: error return without exception set (2005-05-05)
http://python.org/sf/1195984 closed by nbajpai
Wrong word on "raise" page (2005-05-13)
http://python.org/sf/1201438 closed by rhettinger
Glossary listing bug (2005-05-14)
http://python.org/sf/1201807 closed by rhettinger
New / Reopened RFE
__
enhancing os.chown functionality (2005-05-12)
http://python.org/sf/1200804 opened by gyrof
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] python/nondist/peps pep-0343.txt, 1.11, 1.12
[Raymond Hettinger]
> ...
> One more change: 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.
>
> This nuance is likely to be the bane of folks who shift back and forth
> between different levels of precision.
Well, a typical user will never change precision most of the time. Of
the remaining uses, most will set precision once at the start of the
program, and never change it again. Library authors may change
precision frequently, but they should be experts.
> The following example shows the kind of oddity that can arise when
> working with quantities that have not been rounded to the current precision:
>
> >>> from decimal import getcontext, Decimal as D
> >>> getcontext().prec = 3
> >>> D('3.104') + D('2.104')
> Decimal("5.21")
> >>> D('3.104') + D('0.000') + D('2.104')
> Decimal("5.20")
I think it shows more why it was a mistake for the decimal constructor
to extend the standard (the string->decimal operation in the standard
respects context settings; the results differ here because D(whatever)
ignores context settings; having a common operation ignore context is
ugly and error-prone).
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Request for dev permissions
Hello, 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... Reinhold -- Mail address is perfectly valid! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Request for dev permissions
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 [EMAIL PROTECTED] P.S. Do you have a valid email address, RB? I wasn't able to fix up your nospam address by hand. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Adventures with Decimal
[Raymond]
> > The following example shows the kind of oddity that can arise when
> > working with quantities that have not been rounded to the current
> precision:
> >
> > >>> from decimal import getcontext, Decimal as D
> > >>> getcontext().prec = 3
> > >>> D('3.104') + D('2.104')
> > Decimal("5.21")
> > >>> D('3.104') + D('0.000') + D('2.104')
> > Decimal("5.20")
[Tim]
> I think it shows more why it was a mistake for the decimal constructor
> to extend the standard (the string->decimal operation in the standard
> respects context settings; the results differ here because D(whatever)
> ignores context settings;
For brevity, the above example used the context free constructor, but
the point was to show the consequence of a precision change. That
oddity occurs even in the absence of a call to the Decimal constructor.
For instance, using the context aware constructor,
Context.create_decimal(), we get the same result when switching
precision:
>>> from decimal import getcontext
>>> context = getcontext()
>>> x = context.create_decimal('3.104')
>>> y = context.create_decimal('2.104')
>>> z = context.create_decimal('0.000')
>>> context.prec = 3
>>> x + y
Decimal("5.21")
>>> x + z + y
Decimal("5.20")
The whole point of the unary plus operation in the decimal module is to
force a rounding using the current context. This needs to be a standard
practice whenever someone is changing precision in midstream. Most
folks won't (or shouldn't) be doing that, but those who do (as they
would in the PEP's use case) need a unary plus after switching
precision.
As for why the normal Decimal constructor is context free, PEP 327
indicates discussion on the subject, but who made the decision and why
is not clear.
Raymond
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
