But having exceptions without '__traceback__' affects not only the inspect module, but also lots of other code. It will make harder to write generic error reporting code, as you'd need to check for __traceback__ first, and then, if it's None, look for some other, asyncio specific attribute. I think that having tracebacks with fake frames is much more backwards compatible and consistent solution. I don't understand why we should break the established protocol here. [Or we can allow instantiation of immutable frame objects without __code__] Yury On 2014-03-06, 1:32 PM, Guido van Rossum wrote: > But inspect is in the stdlib. Surely changing inspect.py is less > controversial than amending the semantics of frame objects. > > > On Thu, Mar 6, 2014 at 10:10 AM, Xavier Morel <python-dev at masklinn.net>wrote: > >> On 2014-03-06, at 16:52 , Antoine Pitrou <solipsis at pitrou.net> wrote: >>> Le 06/03/2014 16:03, Yury Selivanov a écrit : >>>> On 2014-03-06, 8:42 AM, Antoine Pitrou wrote: >>>>> Le 05/03/2014 23:53, Nick Coghlan a écrit : >>>>>> __traceback__ wouldn't change [...] >>>>> Uh, really? If you want to suppress all reference cycles, you *have* >>>>> to remove __traceback__. >>>>> >>>>> The problem is to make computation of the traceback summary >>>>> lightweight enough that it doesn't degrade performance in the common >>>>> case where you don't have to print the traceback later. >>>> So why can't we allow instantiation of types.TracebackType & >>>> types.FrameType? >>> IMO it is absolutely out of question to allow creation of arbitrary >> frames from Python code, because the structure and initialization of frames >> embody too many low-level implementation details. >>> We might allow the creation of traceback objects, but without any custom >> frame objects it is unclear how useful that would be. >> >> Some bits of the standard library (and probably third-party libraries >> transitively relying on getinnerframes) really, really want traceback >> objects and can't be used with a stack or frames extracted via >> inspect.currentframe() or whatever. For instance cgitb.text calls >> inspect.getinnerframes which accesses param.tb_frame then calls >> getframeinfo(param). getframeinfo blows up if it does not get either an >> actual traceback object or an actual frame object. >> >> A frame object does not have a tb_frame attribute, and will thus fail >> in getinnerframes, a fake traceback object will fail in getframeinfo. >> >> Therefore it's not possible to call cgitb.text outside of an exception >> handling context (that is, not possible to use it as a >> traceback.print_stack providing extra information). If it were possible >> to create traceback objects, there would be no issue there at least. >> _______________________________________________ >> Python-Dev mailing list >> Python-Dev at python.org >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/guido%40python.org >> > > > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/yselivanov.ml%40gmail.com
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4