New submission from Avram:
Checking to see if a log level is enabled can add non-insignificant time to
programs with a large number of logging statements. This issue is to track a
pull request which introduces caching to the logging module so checking to see
if a log level is enabled takes
Avram added the comment:
Yes, though the bottleneck for normal logging is more likely in other areas so
the speedup will be less noticeable. Where I notice it is with debug statements
when debugging is disabled. In that scenario the bulk of the time is spent
checking if the level is enabled
New submission from Avram :
This bug was introduced with Issue25597
Here's some code that demonstrates the error:
import sys
from unittest.mock import patch
with patch.object(sys, 'stdout', wraps=sys.stdout) as mockstdout:
bool(sys.stdout)
This works fine in 3.8
Avram added the comment:
Ah, I see, yes, the documentation is a bit inconsistent. What may make more
sense for some magic methods is to call the underlying object and use the
return value or raise any exception that occurs.
For example:
__bool__ return value is bool(mock._mock_wraps)
__int__
Avram added the comment:
That is not necessarily the same thing, hence why there was a bug.
>>> hasattr(object, '__bool__')
False
>>> bool(object)
True
I think you may be right that magic methods shouldn't magically appear for
wrapped objects, except those that do magi
Avram added the comment:
They are documented. That said, the subsection section could use a header.
https://docs.python.org/3/library/unittest.mock.html#magic-mock
Patch looks good! Can't think of any other test scenarios right now.
--
___
Python
Avram added the comment:
Honestly, I'm not sure if any of the other magic methods behave this way. It
would take a little research or someone more familiar with it.
Here's more info about how __bool__ behaves.
https://docs.python.org/3/reference/datamodel.html#object.__bool__
Avram added the comment:
Checking for presence and then falling through to the <=3.8 behavior as in the
patch, seems reasonable. The default magic method behavior presumably comes out
of research, trial, and error. If the docs need to be clearer, I think that's
different that scrapp
Avram added the comment:
I looked through a lot of the suggested libraries and they all seemed either
too specific to an implementation or didn't fully implement compatibility. So I
created Prefixed to prove out the implementation of of an expanded format
specification for float would look