> On 28 Apr 2019, at 09:12, Ram Rachum wrote:
>
> It's possible, but it would be very cumbersome, for a bunch of reasons. One
> of them is that the tracing code inspects the frame, the variables referenced
> in it, and it even opens the file of the code object of the frame. It will be
> dif
It's possible, but it would be very cumbersome, for a bunch of reasons. One
of them is that the tracing code inspects the frame, the variables
referenced in it, and it even opens the file of the code object of the
frame. It will be difficult to mock all of that, and even if that's
possible, we won'
> On 25 Apr 2019, at 15:51, Ram Rachum wrote:
>
> Hi,
>
> Here's something I want in Python: Multiple levels of tracers working on top
> of each other, instead of just one.
>
> I'm talking about the tracer that one can set by calling sys.settrace.
>
> I've recently released PySnooper: http
> On 26 Apr 2019, at 05:47, Ram Rachum wrote:
>
> Ah, I thought about it now and Ned is right. This would require modifications
> to ceval.c and others.
Pity!
> The question is... Does anyone else think it's a good idea?
I do. It seems to me that coverage is a very useful tool that shouldn
Ah, I thought about it now and Ned is right. This would require
modifications to ceval.c and others.
The question is... Does anyone else think it's a good idea?
On Fri, Apr 26, 2019 at 12:31 AM Ned Batchelder
wrote:
> It wouldn't be difficult to have a list of trace functions, so that every
> l
It wouldn't be difficult to have a list of trace functions, so that
every line of "real" Python executed, would invoke all the trace
functions. But Ram has asked for something more: when the first trace
function is executing, its line should themselves be traced by the
remaining trace function
Well, it would trigger the top level chaining trace function, but they should
be able to decide when to call the sub-trace functions. Hmm... Maybe :)
> On 25 Apr 2019, at 19:16, Ned Batchelder wrote:
>
> Perhaps I misunderstand what's implied by "simple(!) monkeypatch of
> sys.settrace", but t
To clarify, I meant that each trace function would manually call any trace
functions that were registered below it, instead of using the trampoline in
cpython. Does that solve the problem you raised?
On Thu, Apr 25, 2019, 20:20 Ned Batchelder wrote:
> Perhaps I misunderstand what's implied by "s
Perhaps I misunderstand what's implied by "simple(!) monkeypatch of
sys.settrace", but the trickiest part of Ram's proposal is that the body
of one trace function would still trigger the remaining trace
functions. That to me sounds like it's going to require changes to ceval.c
--Ned.
On 4/25
Hmm, looks like, for this to work, you'll need the existing tracer to be
cooperative. Right now there are existing tracers, for example coverage's
tracer and Wing IDE's tracer, and I would need to modify them for your idea
to work, right?
If I understand your idea correctly, the first tracer would
Oh wow, I didn't even consider that. I think you're right, I'll do more
thinking about this. Thanks Anders!
On Thu, Apr 25, 2019 at 6:10 PM Anders Hovmöller
wrote:
> Can't this be implemented today by a simple monkey patch of sys.settrace?
>
> On 25 Apr 2019, at 16:51, Ram Rachum wrote:
>
> Hi,
Can't this be implemented today by a simple monkey patch of sys.settrace?
> On 25 Apr 2019, at 16:51, Ram Rachum wrote:
>
> Hi,
>
> Here's something I want in Python: Multiple levels of tracers working on top
> of each other, instead of just one.
>
> I'm talking about the tracer that one can
Hi,
Here's something I want in Python: Multiple levels of tracers working on
top of each other, instead of just one.
I'm talking about the tracer that one can set by calling sys.settrace.
I've recently released PySnooper: https://github.com/cool-RR/PySnooper/
One of the difficulties I have, is
13 matches
Mail list logo
