Re: [Python-Dev] with_traceback
James Y Knight wrote: > It seems to me that a stack trace should always be attached to an > exception object at creation time Um. Yes. Well, that's certainly an innovative solution... > The traceback won't necessarily be *useful*, Almost completely use*less*, I would have thought. The traceback is mostly used to find out where something went wrong, not where it went right (i.e. successful creation of the exception). > creating the traceback is generally very expensive, I don't think so -- isn't it just a linked list of existing stack frames? That should be very cheap to create. > From http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Throwable.html: > >>A throwable contains a snapshot of the execution stack of its >>thread at the time it was created. This would be a major and surprising change to Python users. It would also be considerably *more* expensive to implement than the current scheme, because it would require copying the entire stack, instead of just linking stack frames together as they are unwound during the search for an exception handler. -- 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] with_traceback
Michael Foord wrote: > With the > proposed changes, modules that do this would *continue* to work, surely > ? Probably, but it might mean they were no longer thread safe. An exception caught and raised in one thread would be vulnerable to having its traceback clobbered by another thread raising the same instance. There's also the possibility of a traceback unexpectedly kept alive causing GC problems -- cycles, files not closed when you expect, etc. -- 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] with_traceback
[EMAIL PROTECTED] wrote: > Perhaps the use-cases for attaching the traceback object > to the exception would be better satisfied by simply having > sys.exc_info() return an object with methods like Failure? > I can't think of a good name for the new object type, Maybe we could call it a 'catch' (used as a noun, as when a fisherman might say "That's a good catch!") -- 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] PEP 306 changes (How to Change Python's Grammar)
Jack Diederich wrote: > __ Python/compile.c: You will need to create or modify the >compiler_* functions for your productions. Python/symtable.c will likely also need attention at this point (it handles the symbol collection pass that occurs before the actual compilation pass) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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 306 changes (How to Change Python's Grammar)
Someone please check this in! On 3/1/07, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Jack Diederich wrote: > > __ Python/compile.c: You will need to create or modify the > >compiler_* functions for your productions. > > Python/symtable.c will likely also need attention at this point (it > handles the symbol collection pass that occurs before the actual > compilation pass) > > Cheers, > Nick. > > -- > Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia > --- > http://www.boredomandlaziness.org > ___ > 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] with_traceback
On Mar 1, 2007, at 3:27 AM, Greg Ewing wrote: > James Y Knight wrote: >> The traceback won't necessarily be *useful*, > > Almost completely use*less*, I would have thought. > The traceback is mostly used to find out where > something went wrong, not where it went right (i.e. > successful creation of the exception). The advantages are that it's an easily understandable and explainable behavior, and the traceback points you (the programmer) to the exact location where you went wrong: creating the exception at module level. Creating an exception with a non-exceptional stacktrace isn't always useless: sometimes you have exceptions where you know you never care about the stacktrace (internal flow control/etc). > This would be a major and surprising change to Python > users. It's only a major change if you don't raise the exception in the same place you create it. (which other people are claiming is extremely rare). > It would also be considerably *more* expensive to implement > than the current scheme, because it would require copying the > entire stack, instead of just linking stack frames together > as they are unwound during the search for an exception > handler. Yes of course, you're right, I withdraw the proposal. I had forgotten that python doesn't currently save the entire stack, only that between the 'raise' and the 'except'. (I had forgotten, because Twisted's "Failure" objects do save and print the entire stacktrace, both above and below the catch-point). James ___ 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] Class destructor
On 2/28/07, Nick Maclaren <[EMAIL PROTECTED]> wrote: > I am gradually making progress with my binary floating-point software, > but have had to rewrite several times as I have forgotten most of the > details of how to do it! After 30 years, I can't say I am surprised. > > But I need to clean up workspace when a class (not object) is > deallocated. I can't easily use attributes, as people suggested, > because there is no anonymous storage built-in type. I could subvert > one of the existing storage types (buffer, string etc.), but that is > unclean. And I could write one, but that is excessive. Can you explain the reason for cleaning up in this scenario? Are you rapidly creating and destroying temporary class objects? Why can't you rely on the regular garbage collection process? Or does you class create an external resource like a temp file? -- --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] with_traceback
On 2/28/07, James Y Knight <[EMAIL PROTECTED]> wrote: > On Feb 28, 2007, at 9:10 PM, Guido van Rossum wrote: > > I am beginning to think that there are serious problems with attaching > > the traceback to the exception; I really don't like the answer that > > pre-creating an exception is unpythonic in Py3k. > > I'll say up front that I haven't been paying as much attention to the > topic of exception behavior as perhaps I should before attempting to > contribute to a thread about it...but... > > It seems to me that a stack trace should always be attached to an > exception object at creation time of the exception, and never at any > other time. Then, if someone pre-creates an exception object, they > get consistent and easily explainable behavior (the traceback to the > creation point). The traceback won't necessarily be *useful*, but > presumably someone pre-creating an exception object did so to save > run-time, and creating the traceback is generally very expensive, so > doing that only once, too, seems like a win to me. I agree. Since by far the most common use case is to create the exception in the raise statement, the behavior there won't be any different than it is today; the traceback on precreated objects will be useless, but folks who precreate them for performance reasons presumably won't care; and those that create global exception instances by mistakenly copying the wrong idiom, well, they'll learn quickly (and a lot more quickly than when we try to override the exception). > FWIW, that's basically how exceptions work in Java. > From http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Throwable.html: > > Instances of two subclasses, Error and Exception, are > > conventionally used to indicate that exceptional situations have > > occurred. Typically, these instances are freshly created in the > > context of the exceptional situation so as to include relevant > > information (such as stack trace data). > > > A throwable contains a snapshot of the execution stack of its > > thread at the time it was created. It can also contain a message > > string that gives more information about the error. Finally, it can > > contain a cause: another throwable that caused this throwable to > > get thrown. The cause facility is new in release 1.4. It is also > > known as the chained exception facility, as the cause can, itself, > > have a cause, and so on, leading to a "chain" of exceptions, each > > caused by another. > > There's probably a million reasons why this doesn't work for python, > but they don't immediately jump out at me. :) Not at me either. Java exceptions weren't around when Python's exceptions were first invented! > Migration from 2.X to 3.X would consist of recommending not to create > an exception outside of a raise line, unless you're okay with the > traceback location changing from the raise point to the creation point. Sounds fine with me. (But I haven't digested Glyph's response.) -- --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] with_traceback
On 2/28/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > On Wed, 28 Feb 2007 18:10:21 -0800, Guido van Rossum <[EMAIL PROTECTED]> > wrote: > >I am beginning to think that there are serious problems with attaching > >the traceback to the exception; I really don't like the answer that > >pre-creating an exception is unpythonic in Py3k. > > In Twisted, to deal with asynchronous exceptions, we needed an object to > specifically represent a "raised exception", i.e. an Exception instance with > its attached traceback and methods to manipulate it. > > You can find its API here: > > http://twistedmatrix.com/documents/current/api/twisted.python.failure.Failure.html > > Perhaps the use-cases for attaching the traceback object to the exception > would be better satisfied by simply having sys.exc_info() return an object > with methods like Failure? Reading the "motivation" section of PEP 344, it > describes "passing these three things in parallel" as "tedious and > error-prone". Having one object one could call methods on instead of a > 3-tuple which needed to be selectively passed on would simplify things. > > For example, chaining could be accomplished by doing something like this: > > sys.current_exc_thingy().chain() > > I can't think of a good name for the new object type, since "traceback", > "error", "exception" and "stack" all already mean things in Python. I'm guessing you didn't see James Knight's proposal. If we can agree on more Java-esque exception semantics, the exception object could serve this purpose just fine. I'm thinking that in that case an explicit with_traceback(tb) should perhaps clone the exception; the clone could be fairly simple by constructing a new uninitialized instance (the way unpickling does) and filling its dict with a copy of the original's dict, overwriting the traceback. (Also, if Brett's exception reform is accepted, we should call this attribute just traceback, not __traceback__.) -- --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] with_traceback
[Summary: James Knight's idea can't work unless we copy the entire stack, which is bad. Disregard my previous posts in this thread of a few minutes ago. See the end of this post why.] On 3/1/07, Greg Ewing <[EMAIL PROTECTED]> wrote: > James Y Knight wrote: > > > It seems to me that a stack trace should always be attached to an > > exception object at creation time > > Um. Yes. Well, that's certainly an innovative solution... In the Python context perhaps, but given the Java precedent I would hardly call it innovative. > > The traceback won't necessarily be *useful*, > > Almost completely use*less*, I would have thought. > The traceback is mostly used to find out where > something went wrong, not where it went right (i.e. > successful creation of the exception). Which is one opcode before it is raised, in 99.99% of all cases. > > creating the traceback is generally very expensive, > > I don't think so -- isn't it just a linked list > of existing stack frames? That should be very cheap > to create. This is a difference between Python and Java that we should preserve. Java's traceback is a string; Python's is a linked list of traceback objects > > From http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Throwable.html: > > > >>A throwable contains a snapshot of the execution stack of its > >>thread at the time it was created. > > This would be a major and surprising change to Python > users. > > It would also be considerably *more* expensive to implement > than the current scheme, because it would require copying the > entire stack, instead of just linking stack frames together > as they are unwound during the search for an exception > handler. Oh bah, you're right. This sounds like a deal killer c.q. show shopper. In my earlier responses forgot the details of how Python exceptions work. You start with a traceback object pointing to the current frame object (traceback objects are distinct from frame objects, they are linked in the *opposite* direction, so no cycles are created); then each time the exception bubbles up a stack frame, a new traceback object pointing to the next frame object is inserted in front of the traceback. This requires updating the traceback pointer each time we bubble up a frame. Then when you catch the exception, the chain of tracebacks points to all frames between the catching and the raising frame (I forget whether catching frame is included). Since this can conceivably be going on in parallel in multiple threads, we really don't ever want to be sharing whatever object contains the head of the chain of tracebacks since it mutates at every frame bubble-up. I guess our next best option would be Glyph's suggested object to represent a caught exception, which could indeed be named "catch" per Greg's suggestion. The next-best option would be to clone the exception object whenever it is raised, but that seems wasteful in the normal case. -- --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] with_traceback
Guido van Rossum wrote: > You start with a traceback object pointing to the current frame > object (traceback objects are distinct from frame objects, Just out of curiosity, is it really necessary to have a distinct traceback object? Couldn't the traceback just be made of dead frame objects linked the opposite way through their f_next pointers? Seems to me it would be advantageous if raising an exception (once it's created) could be done without having to allocate any memory. Otherwise you could get the situation where you're trying to raise a MemoryError, but there's no memory to allocate a traceback object, so you raise a MemoryError... etc... That might be a reason for pre-allocating the MemoryError exception, too. -- 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] with_traceback
On 3/1/07, Greg Ewing <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > You start with a traceback object pointing to the current frame > > object (traceback objects are distinct from frame objects, > > Just out of curiosity, is it really necessary to have > a distinct traceback object? Couldn't the traceback > just be made of dead frame objects linked the opposite > way through their f_next pointers? That would be rather fragile; there's tons of code that follows f_next pointers, without regard for whether the frame is alive or dead. Using a separate pointer would be a possibility, but it would probably still mean setting the f_next pointers to NULL to avoid hard cycles. Maybe this idea could be used for a new VM design though. > Seems to me it would be advantageous if raising an > exception (once it's created) could be done without > having to allocate any memory. Otherwise you could > get the situation where you're trying to raise a > MemoryError, but there's no memory to allocate a > traceback object, so you raise a MemoryError... > etc... > > That might be a reason for pre-allocating the > MemoryError exception, too. I think it is preallocated. -- --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
