Antoine Pitrou wrote:
On Mon, 28 Jun 2010 13:14:21 +0200 "M.-A. Lemburg" firstname.lastname@example.org wrote:
BTW: I wonder why proxy objects don't provide a direct access to the weakref object they are using. That would make keeping that extra variable around unnecessary.
Probably because the proxy would then have an additional attribute which isn't on the proxied object. Or, worse, it could also shadow one of the proxied object's existing attributes.
That's a very weak argument, IMHO. It all depends on the naming of the attribute. Also note that the proxied object won't know anything about that attribute, so it doesn't have any side-effects.
We've used such an approach on our mxProxy object for years without any problems or naming conflicts so far:
Perhaps someone could highlight a use case where the traceback is needed outside the except clause ?!
Well, it's needed if you want delayed error reporting and still display a comprehensive stack trace (rather than just the exception message). Frameworks often need this kind of behaviour; Twisted was already mentioned in this thread. But, even outside of frameworks, there are situations where you want to process a bunch of data and present all processing errors at the end.
I had already given that example myself, but in those cases I had in mind the stack trace is not really needed: instead, you add the relevant information to the list of errors directly from the except clause, since the error information needed to report the issues is not related to programming errors, but instead to data errors.
However, as the OP argued, most often you need the traceback in order to display file names and line numbers, but you don't need the attached variables (locals and globals).
I guess all this just needs to be highlighted in the documentation to make programmers aware of the fact that they cannot just store exception objects away without considering the consequences of this first.