This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Allow log calls to return True for code optimization.
Type: enhancement Stage:
Components: Library (Lib) Versions: Python 3.4
process
Status: closed Resolution: works for me
Dependencies: Superseder:
Assigned To: Nosy List: Lluís, r.david.murray, serhiy.storchaka, vinay.sajip
Priority: normal Keywords:

Created on 2012-05-21 07:56 by Lluís, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (7)
msg161251 - (view) Author: Lluís (Lluís) Date: 2012-05-21 07:56
One of the problems with the logging library is that it can affect code performance when logging calls are over-utilized.

One possible solution would be to allow the compiler to remove logging calls when code is optimized with "python -O" by wrapping log calls with an assert:

   assert logging.debug("This is a test.")

Note that now debug(), info(), etc in the logging module always return "None" and this is not possible. An enhancement would be to make all logging calls to return True. In normal conditions messages would be logged without raising any error, but in optimized code they would never be called.

It is really easy to implement and I would be pleased to provide a patch for this, but I want to receive feedback from python core developers.

Thanks…
msg161254 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2012-05-21 08:50
assert logging.debug("This is a test.") or True
msg161255 - (view) Author: Lluís (Lluís) Date: 2012-05-21 09:08
storchaka, you're right, but since non of the debug(), info() etc. functions have a return value, it would cause no trouble and would be neater to add a "return True". I'm not sure, but probably also more efficient.
msg161260 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-05-21 11:19
I would also, however, not be a typical Python coding pattern.  Functions normally return None by default.  The 'assert....or True' pattern makes it reasonably clear what the intent is, which just having logging return True would not, particularly.  As for efficiency, since your are using the assert to improve the efficiency in -O case, the efficiency in the non -O case becomes less important.

I'm -1 on this suggestion (given that there is an easy way to spell what you want to do).  But we can let Vinay decide :)

There is also another way to spell it, by the way:

   if __debug__: 
       logger.debug('log it')

That is even clearer as to intent.  In fact, I'd be inclined to call that TWOWTDI (The One Obvious Way To Do It).
msg161261 - (view) Author: Lluís (Lluís) Date: 2012-05-21 11:26
David, the problem is that if you have the logging inside a loop, the interpreter will have to evaluate the condition every time. With an assert you guarantee that *no code* is executed.

I know that we can find thousands of ways to do that, even writing a dynamic proxy for the Logger, and wrap the debug(), error() calls and return True, etc.

My is not telling developers to write "assert logger.debug('aa')" every time that they want to log something, but instead giving them the option to do that and be sure that *no code* is executed. Specially, because the return value of log functions is not used at all.

Thanks for the responses.
msg161267 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-05-21 11:55
I was definitely wrong about the "obvious" part, then.  The 'if __debug__:' idiom is completely optimized away by -O, just like asserts are.  That is, in -O mode, there is no if test, the code block is just omitted entirely.

Having said that, though, I can't find it documented other than by the implicit equivalence given in the assert docs.

Hmm.  Yes, it does seem to be a CPython implementation detail.  See issue 8379.  Assert being removed is also an implementation detail, though (see the reference to "the current code generator..." in the assert docs).  I suppose that '-O' itself is a CPython implementation detail, in a sense :)
msg161269 - (view) Author: Lluís (Lluís) Date: 2012-05-21 12:01
Thanks for the explanation, I didn't know of the exact behavior of __debug__.

I close ticket.
History
Date User Action Args
2022-04-11 14:57:30adminsetgithub: 59073
2012-05-21 12:01:01Lluíssetstatus: open -> closed
resolution: works for me
messages: + msg161269
2012-05-21 11:55:23r.david.murraysetmessages: + msg161267
2012-05-21 11:26:10Lluíssetmessages: + msg161261
2012-05-21 11:19:59r.david.murraysetnosy: + r.david.murray, vinay.sajip
messages: + msg161260
2012-05-21 09:08:42Lluíssetmessages: + msg161255
2012-05-21 08:50:58serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg161254
2012-05-21 07:56:08Lluíscreate