On 10/3/2018 1:40 AM, Nathaniel Smith wrote:
On Tue, Oct 2, 2018 at 8:44 PM, David Teresi <dkter...@gmail.com
<mailto:dkter...@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
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
