On Thu, Jul 18, 2019 at 3:17 PM Andrew Barnert <[email protected]> wrote:
> On Jul 18, 2019, at 14:50, Yonatan Zunger <[email protected]> wrote: > > > > Even that isn't so simple, because these need to vanish when the frame > does (you wouldn't want the dict to hold a reference to the frame!). > > Yes, and settrace takes care of that: the dict _can_ hold a reference to a > frame, because you get a “return” trace action exactly when a frame is > going away, so you can remove the reference then. > > (That’s also exactly what weakrefs are for, but unfortunately you can’t > weakref a frame, which is why I suggested settrace.) > > Obviously settrace has a performance cost. Plus, using it for scope > painting interferes with using it for anything else, which could be a > problem for some of the kinds of uses you’re talking about. So, it’s not a > production solution. But considering how trivial it should be slap together > something that works in Python 3.7, it may be good enough for a demo. > > Ah, good point! I'd forgotten that this could be done with settrace. > > Also, most of the libraries that would be using this (cprofile, > tracemalloc, traceback, the new profiler I'm working on) are in C, so it > wouldn't be a straightforward monkeypatch. > > traceback is in Python. tracemalloc is also in Python (with C support from > _tracemalloc, but the stuff you want to patch is in Python). cProfile is in > C, but you can use profile instead, which is in Python. (On this one, the > performance may mean it’s not acceptable for many uses, but it would still > be usable for some—which is why profile is there, after all. In fact, > “easier to extend” is its documented reason for existence.) Whatever new > profiler you’re working on is new code not part of Python 3.7, so it > doesn’t need to be monkeypatched in the first place. > > Also, you don’t have to patch _everyrhing_ for a demo, just the modules > needed for that demo. Something that stashes network peer names in > tracebacks for logging (I think that was one of your uses?) will work fine > without patching profile or tracemalloc, right? > > Maybe it would be easier for me to just slap together a quick&dirty > prototype than to try to explain it? > Nope, I see what you're saying now; with settrace it would make sense. (Although I'm still not sure it would work for the cases I'm thinking of; the C helpers are doing a lot of the lifting in this case) > > > What would the goal of an effective demo be? > > To show people actual output rather than describing it in general terms > and hoping they can see why it might be helpful. To let them use it on > their own code and see whether it can do what they want from it. All the > usual reasons a demo is useful when trying to sell people on a feature. > I guess the real question is, who would the intended audience for this demo be, and how might they want it presented? (I've never built a demo for this audience before so I want to make sure I cover the things people care about)
_______________________________________________ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/CR2IDAGSL6EKRNFQQBHYDLGL3OKHRVRS/ Code of Conduct: http://python.org/psf/codeofconduct/
