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.

> 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?

> 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.

_______________________________________________
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/XFCL2KVSC2U6U6XGXPJ6OH3AOH5MWYI6/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to