Kevin Dangoor wrote: > On 4/26/06, Simon Belak <[EMAIL PROTECTED]> wrote: >> I would just like to highlight some (breaking) changes I made in r1257. >> For now all are intended for First Class, if we decide anything should >> be released beforehand I will merge than (I hope this covers me from >> Michelle's wrath ;)). > > Please document breaking changes in the CHANGELOG, otherwise we'll > have no hope of producing a migration guide when 1.1 comes out.
Will do. > >> 1) Fail-safe mechanism is uncoupled from error handling and validate() >> decorator. Some examples can be had in test_errorhandling.py (should >> probably refactor as well), I will update the "docs" soon (on sprint at >> the latest). > > We'll need to get docs going for 1.1 right away as well. Maybe it > would make sense to start the migration guide from the get go. +1 > >> 2) tg_exceptions is renamed to tg_exception and is in fact no longer an >> exception as such, but a tuple compatible with what sys.exc_info() returns. >> (it should be possible to do some pretty sick things with stack >> manipulation now ...) > > We need to be careful about memory leaks. I seem to remember reading > something in the docs about some deep voodoo around the stack frames > in exceptions that could cause the frames to stick around. It's cleaned up automatically albeit with a performance hit. From the docs: Warning: Assigning the traceback return value to a local variable in a function that is handling an exception will cause a circular reference. This will prevent anything referenced by a local variable in the same function or by the traceback from being garbage collected. Since most functions don't need access to the traceback, the best solution is to use something like exctype, value = sys.exc_info()[:2] to extract only the exception type and value. If you do need the traceback, make sure to delete it after use (best done with a try ... finally statement) or to call exc_info() in a function that does not itself handle an exception. Note: Beginning with Python 2.2, such cycles are automatically reclaimed when garbage collection is enabled and they become unreachable, but it remains more efficient to avoid creating cycles. I'm not completely certain what "a function that does not itself handle an exception" means. Any ideas, or do I need to rummage through Python source? Cheers, Simon P.S. my (by now infamous) commit message was obviously a screw-up, will redeem myself with a nice juicy changelog. ;) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk -~----------~----~----~----~------~----~------~--~---
