Re: [Python-Dev] Example for PEP 343
Guido van Rossum wrote: 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 For the 'with' keyword, and the appropriate __enter__/__exit__ methods on decimal Contexts, this can be written: with decimal.getcontext() as ctx: ctx.prec += 2 # change other settings # algorithm goes here # Pre-with context guaranteed to be restored here The decimal.Context methods to make this work: def __enter__(self): current = getcontext() if current is self: self._saved_context = self.copy() else: self._saved_context = current setcontext(self) def __exit___(self, *exc_info): if self._saved_context is None: raise RuntimeError(No context saved) try: setcontext(self._saved_context) finally: self._saved_context = None Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Request for dev permissions
Robert P.S. Do you have a valid email address, RB? I wasn't able to fix Robert up your nospam address by hand. That's because it didn't need fixing... Note Reinhold's sig: Reinhold -- Reinhold Mail address is perfectly valid! wink Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal construction
On Wed, May 18, 2005, Tim Peters wrote: 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). Not sure what the right answer is, but I wanted to stick my oar in to say that I think that Decimal has not been in the field long enough or widely-enough used that we should feel that the API has been set in stone. If there's agreement that a mistake was made, let's fix it! -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ And if that makes me an elitist...I couldn't be happier. --JMS ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 344: Exception Chaining and Embedded Tracebacks
Here's another rule-of-thumb: when the VM and the user *share* the attribute space of an object, the VM uses system attributes; the VM uses plain attributes for objects that it owns completely (like code objects, frames and so on, which rarely figure user code except for the explicit purpose of introspection). So I think the PEP should continue to use __traceback__ etc. On 5/17/05, Greg Ewing [EMAIL PROTECTED] wrote: 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. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Example for PEP 343
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.) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup
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/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup
At 09:39 AM 5/18/2005 -0700, Guido van Rossum wrote: - 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(). And there was much rejoicing in the land of the co-routiney people. :) +1000. Should this maybe just be added to PEP 342? To me, PEP 342 has always seemed incomplete without ways to throw() and close(), but that could easily be just me. In any case I'd expect the implementation of 'next(arg)' to have some overlap with the implementation of 'throw()'. Also, if the generator yields a value upon close(), shouldn't that throw a runtime error? Otherwise, you have no way to know the generator's exception handling is broken. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup
[Phillip J. Eby] And there was much rejoicing in the land of the co-routiney people. :) +1000. Should this maybe just be added to PEP 342? To me, PEP 342 has always seemed incomplete without ways to throw() and close(), but that could easily be just me. In any case I'd expect the implementation of 'next(arg)' to have some overlap with the implementation of 'throw()'. Maybe, but on the other hand this idea can be done independently from PEP 342. After the monster-PEP 340, I'd rather break proposals up in small parts. Also, if the generator yields a value upon close(), shouldn't that throw a runtime error? Otherwise, you have no way to know the generator's exception handling is broken. Maybe. But then what should happen when this happens to close() invoked by the GC? I guess the same as when a __del__() method raises an exception -- print a traceback and go on. OK, works for me. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Simpler finalization semantics (was Re: PEP 343 -Abstract Block Redux)
[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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 - Abstract Block Redux
Greg Ewing [EMAIL PROTECTED] writes: Guido van Rossum wrote: PEP 340 is still my favorite, but it seems there's too much opposition to it, I'm not opposed to PEP 340 in principle, but the ramifications seemed to be getting extraordinarily complicated, and it seems to be hamstrung by various backwards-compatibility constraints. E.g. it seems we can't make for-loops work the way they should in the face of generator finalisation or we break old code. I think I zoned this part of the discussion out, but I've written code like this: lineiter = iter(aFile) for line in lineiter: if sectionmarker in line: break parseSection1Line(line) for line in lineiter: if sectionmarker in line: break parseSection2Line(line) (though, not *quite* that regular...) This is, to me, neat and clear. I don't find the idea that iterators are tied to exactly 1 for loop an improvement (even though they usually will be). Cheers, mwh -- thirmite what's a web widget?? glyph thirmite: internet on a stick, on fire Acapnotic with web sauce! -- from Twisted.Quotes ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup
At 09:55 AM 5/18/2005 -0700, Guido van Rossum wrote: [Phillip J. Eby] And there was much rejoicing in the land of the co-routiney people. :) +1000. Should this maybe just be added to PEP 342? To me, PEP 342 has always seemed incomplete without ways to throw() and close(), but that could easily be just me. In any case I'd expect the implementation of 'next(arg)' to have some overlap with the implementation of 'throw()'. Maybe, but on the other hand this idea can be done independently from PEP 342. After the monster-PEP 340, I'd rather break proposals up in small parts. Okay. Maybe we should just update PEP 325, then? It has much of the stuff that we'd want in the new PEP, such as the rationale. Your new proposal, AFAICT, is just a simple extension of the PEP 325 protocol (i.e., adding 'throw()'), along with some decisions to resolve its open issues. Even the addition of 'throw()' seems tacitly approved by this bit at the end: Were PEP 288 implemented, Exceptions Semantics for close could be layered on top of it So at this point it seems your proposal is just nailing down specifics for the open parts of PEP 325. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup
[Phillip J. Eby] Okay. Maybe we should just update PEP 325, then? It has much of the stuff that we'd want in the new PEP, such as the rationale. Your new proposal, AFAICT, is just a simple extension of the PEP 325 protocol (i.e., adding 'throw()'), along with some decisions to resolve its open issues. Even the addition of 'throw()' seems tacitly approved by this bit at the end: Were PEP 288 implemented, Exceptions Semantics for close could be layered on top of it So at this point it seems your proposal is just nailing down specifics for the open parts of PEP 325. Or PEP 288? That has throw() (albeit with a different signature). I could do without the attributes though (PEP 342 provides a much better solution IMO). If either of those PEP authors feels like updating their PEP, they have my blessings! I probably won't get to writing my own for a few more days. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Combining the best of PEP 288 and PEP 325:generator exceptions and cleanup
Should this maybe just be added to PEP 342? To me, PEP 342 has always seemed incomplete without ways to throw() and close(), but that could easily be just me. In any case I'd expect the implementation of 'next(arg)' to have some overlap with the implementation of 'throw()'. Maybe, but on the other hand this idea can be done independently from PEP 342. After the monster-PEP 340, I'd rather break proposals up in small parts. +1 I want this as a separate PEP. It is a straight-forward solution to long standing issues. I would rather not have it contaminated with distracting issues and co-routine dreams. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup
Okay. Maybe we should just update PEP 325, then? -1. Keep this separate. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generatorexceptions and cleanup
[Raymond Hettinger] Are the value and traceback arguments optional as they are with the current raise statement? If they are optional, what would the default be? I think the preferred choice is to have the call to the throw method be the anchor point. That makes sense in a traceback so you can see who threw the exception. AFAI throw() is concerned, the defaults are None. The raise statement does something sane when the second and/or third arg are None (the first can't be though). The alternative is to have the generator resumption point be the anchor. That is closer to the notion that throw(ex) is equivalent to a raise ex following the last yield. This probably isn't the way to go but the PEP should address it explicitly. It's actually kind of tricky since the exception will come *back* to the throw point anyway. I think the traceback ought to start at the resumption point by default. 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. The parallel to next() makes this easy to understand, learn, and implement. However, there are some disadvantages to passing through a StopIteration. It means that throw() calls usually need to be wrapped in a try/except or that a generator's exception handler would terminate with a yield None where a return would be more natural. As a example, it is a bit painful to simulate the effects of g.close() using g.throw(GeneratorExit). Doesn't bother me; the main use case is in the do_template (or with_template) decorator. Since it must support both raising an exception and returning a value, we're pretty much forced to catch the exception (unless we just want to pass it through, which is actually a reasonable use case). 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(). +0 The switch from __next__() to next() is attractive but not essential to the proposal. Besides a small cost to backwards compatability, it introduces yet another new/old style distinction where we have to keep both forms in perpetuity. Right. PBP. :-) FWIW, I'm in agreement with everything. I hope this one gets accepted. Please do put it in a separate PEP. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generatorexceptions and cleanup
At 01:24 PM 5/18/2005 -0400, Raymond Hettinger wrote: - g.throw(type, value, traceback) causes the specified exception to be thrown at the place where the generator g is currently suspended. Are the value and traceback arguments optional as they are with the current raise statement? If they are optional, what would the default be? I think the preferred choice is to have the call to the throw method be the anchor point. That makes sense in a traceback so you can see who threw the exception. The alternative is to have the generator resumption point be the anchor. That is closer to the notion that throw(ex) is equivalent to a raise ex following the last yield. This probably isn't the way to go but the PEP should address it explicitly. My use case for throw() calls for the latter option; i.e., the exception is raised by the yield expression at the resumption point. Keep in mind that if the exception passes out of the generator, the throw() call will show in the traceback anyway. It's unlikely the generator itself will inspect the traceback and need to see the throw() call as if it were nested. 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. The parallel to next() makes this easy to understand, learn, and implement. However, there are some disadvantages to passing through a StopIteration. It means that throw() calls usually need to be wrapped in a try/except or that a generator's exception handler would terminate with a yield None where a return would be more natural. As a example, it is a bit painful to simulate the effects of g.close() using g.throw(GeneratorExit). I don't see this as a big problem, personally, but that's because all of my use cases for throw() will be using only one piece of code that calls throw(), and that code will be overall simplified by the availability of throw(). It's also easy to write a wrapper for control-flow signals of the kind you used in PEP 288: def send(gen, *exc): try: return gen.throw(*exc) except StopIteration: pass ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup
At 01:28 PM 5/18/2005 -0400, Raymond Hettinger wrote: Okay. Maybe we should just update PEP 325, then? -1. Keep this separate. Have you read PEP 325 lately? Mostly the change would consist of deleting rejected options or moving them to a rejected options section. The only other change would be adding a short section stating how throw() would work and that it's being made public to support the future use of generators as flow-control templates. A new PEP would have to copy, reinvent, or reference large chunks of PEP 325, resulting in either redundancy or excess complexity. Or are you suggesting a new PEP for throw(), containing *only* an explanation of its semantics, and then modifying PEP 325 to indicate that it will be implemented using the new PEP's 'throw()'? That's about the only scenario that makes sense to me for adding a new PEP, because PEP 325 is already pretty darn complete with respect to close() and GC. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Combining the best of PEP 288 and PEP 325:generator exceptions and cleanup
So at this point it seems your proposal is just nailing down specifics for the open parts of PEP 325. Or PEP 288? That has throw() (albeit with a different signature). I could do without the attributes though (PEP 342 provides a much better solution IMO). If either of those PEP authors feels like updating their PEP, they have my blessings! I probably won't get to writing my own for a few more days. Okay, I volunteer to recast PEP 288 to encompass your combined proposal. Will tackle it in the morning. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Simpler finalization semantics (was Re: PEP 343 - Abstract Block Redux)
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup
[Guido van Rossum] 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?) ... Nick hasn't submitted it for a PEP number yet. -- David Goodger http://python.net/~goodger signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Adding content to exception messages
Sorry if this message is not a direct reply to Ka-Ping Yee message on PEP344, I'm in vacation in China and there's a thing I must say that could make sense in PEP344. I do a lot of exception re-raising at work; I use that technique to add content to exception messages while keeping the original stack. I even created a reraise function that I use that way: try: parser.parseFile(file) exeption Exception, exception: reraise(exception, Error at line %s in file %s % (x,y)) (x,y) are details, but you get the idea. This very useful in many situations. In the example, it works when an error is happening in parsing a file including other files (like xml files with xs:include). That way you get the exact path of inclusion leading to the error. It is also useful when an error happen in very generic code and when traceback is not enough to know which element was causing the error. What I propose is that all exceptions objects have a standard way to add additional informations. Something like: try: foo() except Exception, exception: exception.add_info(some info) raise exception from (whatever the proposition is) You might ask, why not just reraise a new exception?. It is more useful to reraise the same exception type, making it possible to use selective except clauses and (avoid problems with code using them like hasattr). I think what would be simpler is not affect __str__ representation and prepend to a list the additional infos inside the exception object, adding a function to get these infos. I don't mind how it would be done in fact, as long as the need is fulfilled. I won't be able to read my messages often for the next 10 days, but I hope others will see the point I try to bring;) Regards, Nicolas Discover Yahoo! Have fun online with music videos, cool games, IM and more. Check it out! http://discover.yahoo.com/online.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generatorexceptions and cleanup
Phillip J. Eby wrote: My use case for throw() calls for the latter option; i.e., the exception is raised by the yield expression at the resumption point. Keep in mind that if the exception passes out of the generator, the throw() call will show in the traceback anyway. It's unlikely the generator itself will inspect the traceback and need to see the throw() call as if it were nested. There mightn't be much choice anyway. If the frame making the call to throw() were to be made the starting point for the traceback, and the exception propagated back to the throw, something would try to put the same frame in the traceback twice, which can't work since it's a linked list. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
