[Python-ideas] f-string "debug" conversion

[Eric V. Smith]

On 10/3/2018 1:40 AM, Nathaniel Smith wrote:
> On Tue, Oct 2, 2018 at 8:44 PM, David Teresi <dkteresi at gmail.com 
> <mailto:dkteresi at gmail.com>> wrote:
>  > print(f'{value!d}') is a lot of symbols and boilerplate to type out 
> just for
>  > a debugging statement that will be deleted later. Especially now that
>  > breakpoint() exists, I can't really see myself using this.
>  >
>  > I also don't see the use case of it being within an f-string, because 
> I've
>  > never had to interpolate a debug string within some other string or 
> format
>  > it in a fancy way. You said it yourself, taking advantage of other 
> f-string
>  > features isn't very useful in this case.
>  >
>  > If other people can find a use for it, I'd suggest making it ita own
>  > function -- debug(value) or something similar.
> 
> There was some discussion of this back in April:
> 
> https://mail.python.org/pipermail/python-ideas/2018-April/050113.html

Worth pointing out from that discussion is the "q" library: 
https://pypi.org/project/q/. I got excited about it back then, but never 
installed it.

> I think the way I'd do it would be:
> 
> Step 1: Take the current "lnotab" that lets us map bytecode offsets -> 
> line numbers, and extend it with more detailed information, so that we 
> can map e.g. a CALL operation to the exact start and end positions of 
> that call expression in the source. This is free at runtime, and would 
> allow more detailed tracebacks (see [1] for an example), and more 
> detailed coverage information. It would definitely take some work to 
> thread the necessary information through the compiler infrastructure, 
> but I think this would be a worthwhile feature even without the debug() 
> use case.
> 
> Step 2: Add a 'debug' helper function that exploits the detailed 
> information to reconstruct its call, by peeking into the calling frame 
> and finding the source for the call. Of course this would be a strange 
> and ugly thing to do for a regular function, but for a debugging helper 
> it's reasonable. So e.g. if you had the code:
> 
>    total = debug(x) + debug(y / 10)
> 
> The output might be:
> 
>    debug:myfile.py:10: 'x' is 3
>    debug:myfile.py:10: 'y / 10' is 7

I'm not positive, but isn't this what q does?

Eric