[Python-ideas] Non-intrusive debug logging

Chris Barker - NOAA Federal chris.barker at noaa.gov
Thu Jan 25 11:13:17 EST 2018

This strikes me as something a debugger should do, rather than the regular

And using comment-based syntax means that they would get ignored by the
regular interpreter— which is exactly what you want.

As for a decoration approach— that wouldn’t let you do anything on a line
by line basis.


Sent from my iPhone

On Jan 25, 2018, at 2:44 AM, Stéfane Fermigier <sf at fermigier.com> wrote:

Some thoughts:

1. I too dislikes the idea of using comments as semantically significant

I think it's quite OK for annotation that are aimed at external tools (e.g.
'# nocover' or '# noqa') but not for runtime behavior.

2. It's probably possible do do interesting things using decorators at the
function / class level.

The "q" project (https://pypi.python.org/pypi/q) already does some useful
things in that direction.

Still, when using q (or another decorator-based approach), you need to
first 'import q', which means that you can easily end up with spurious
'import q' in your code, after you're done debugging. Or even worse, commit
them but forget to add 'q' in your setup.py / requirements.txt / Pipfile,
and break CI or production.

3. Doing things unintrusively at the statement level seems much harder.


On Thu, Jan 25, 2018 at 6:54 AM, Steve Barnes <gadgetsteve at live.co.uk>

> On 24/01/2018 23:25, Larry Yaeger wrote:
> > Everyone uses logging during code development to help in debugging.
> Whether using a logging module or plain old print statements, this usually
> requires introducing one or (many) more lines of code into the model being
> worked on, making the existing, functional code more difficult to read.  It
> is also easy to leave logging code in place accidentally when cleaning up.
> I have a possibly odd suggestion for dramatically improving debug logging,
> in an almost automated fashion, without any of the usual problems.  I'm
> willing to jump through PEP hoops, but won't waste anyone's time arguing
> for the idea if others don't embrace it.
> >
> > In brief, make an extremely succinct comment, such as "#l" or "#dbgl",
> semantically meaningful.  If appended to a line of code, such as:
> >
> > x = 1
> > Y = 2
> > Z = 3
> > x = y + z  #l
> >
> > When executed the line would be logged (presumably to stdout) as
> something like:
> >
> > x=1 -> y=2 + z=3 -> 5
> >
> > In one log line you see the variables and their values, the operations
> being performed with them, and the result of the evaluated expression.
> >
> > Placing "#l" on a def Function() line would apply "#l" logging to every
> line in that function or method.
> >
> > That's it.  Adding these log requests would be easy and not clutter the
> code.  Removing them reliably would be a trivial global operation in any
> text editor.  The resulting debug information would be fully diagnostic.
> >
> > Of course there are lots of details and edge cases to consider.  There
> always are.  For example, what if x had not been previously defined?  A
> reasonable answer:
> >
> > x=. -> y=2 + z=3 -> 5
> >
> > In every case the solution should minimize volume of output while
> maximizing logged information.
> >
> > One can debate the precise formatting of the output.  The text used for
> the semantically meaningful comment string is open to debate.  The output
> pipe could be made controllable.  There are natural extensions to allow
> periodic and conditional logging.  I have ideas for reducing (already
> unlikely) collisions with existing comments.  But I want to keep this
> simple for now, and I think this captures the core of the idea.
> >
> > For your consideration.
> >
> > - larryy
> > _______________________________________________
> > Python-ideas mailing list
> > Python-ideas at python.org
> > https://eur02.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fmail.python.org%2Fmailman%2Flistinfo%2Fpython-
> ideas&data=02%7C01%7C%7C1833282b2db342f6476308d563825af0%
> 7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636524333870912999&sdata=
> K5Qd3iat2NG4h%2F1rgIf4C9FOmv8%2Fa%2FUN23I3jOiW0PU%3D&reserved=0
> > Code of Conduct: https://eur02.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fpython.org%2Fpsf%2Fcodeofconduct%2F&data=02%7C01%7C%
> 7C1833282b2db342f6476308d563825af0%7C84df9e7fe9f640afb435aaaaaaaa
> aaaa%7C1%7C0%7C636524333870912999&sdata=TcZ2QLkZ0rDntMEQvouNFFnzn7HBBB
> T64cb%2ByrdIDj8%3D&reserved=0
> >
> I thing that this idea has some merit, obviously with some details to be
> worked out as well.
> I would suggest, however, that if this feature is introduced it be
> controlled via a run-time switch &/or environment variable which
> defaults to off. Then rather than the developer having to do global
> replaces they simply turn off the switch (or reduce it to zero).
> It may also be preferable to use decorators rather than syntactically
> significant comments, (personally I don't like the latter having had too
> many bad experiences with them).
> --
> Steve (Gadget) Barnes
> Any opinions in this message are my personal opinions and do not reflect
> those of my employer.
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/

Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier -
Founder & CEO, Abilian - Enterprise Social Software -
Chairman, Free&OSS Group / Systematic Cluster -
Co-Chairman, National Council for Free & Open Source Software (CNLL) -
Founder & Organiser, PyData Paris - http://pydata.fr/
“You never change things by fighting the existing reality. To change
something, build a new model that makes the existing model obsolete.” — R.
Buckminster Fuller

Python-ideas mailing list
Python-ideas at python.org
Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180125/ad98e4d3/attachment-0001.html>

More information about the Python-ideas mailing list