[issue31749] Request: Human readable byte amounts in the standard library

[Avram]

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 like.

It implements 3 new format types:
- h: SI Decimal prefix (..., n, μ, m, k, M, G, ...)
- j: IEC Binary prefix (Ki, Mi, Gi, ...)
- J: Shortened IEC Binary prefix (K, M, G, ...)

It also implements a new flag, '!' that will add a space before the prefix.

For now, the math is pretty simple, if you cross a magnitude level it will go 
to that prefix. So 999 would be '999' and 1000 would be 1k.

I was thinking another format specification option '%' followed by a digit 
could be used to set the threshold of when to switch, so f'{950.0:%5.2h}' would 
be '0.95k', but f'{949.0:%5.2h}' would be '949.00'. Was going to think about it 
a little more before implementing.

I'd appreciate feedback on the library. Issues can be submitted here: 
https://github.com/Rockhopper-Technologies/prefixed/issues

https://pypi.org/project/prefixed/

--
nosy: +aviso

___
Python tracker 
<https://bugs.python.org/issue31749>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39966] mock 3.9 bug: Wrapped objects without __bool__ raise exception

[Avram]

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 scrapping the whole approach.

--

___
Python tracker 
<https://bugs.python.org/issue39966>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39966] mock 3.9 bug: Wrapped objects without __bool__ raise exception

[Avram]

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__

--

___
Python tracker 
<https://bugs.python.org/issue39966>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39966] mock 3.9 bug: Wrapped objects without __bool__ raise exception

[Avram]

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 magically appear, like __bool__.

--

___
Python tracker 
<https://bugs.python.org/issue39966>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39966] mock 3.9 bug: Wrapped objects without __bool__ raise exception

[Avram]

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__ return value is int(mock._mock_wraps)
__lt__ return value is operator.lt(mock._mock_wraps, other)

This would take care of several of them and provide more consistent behavior 
with the wrapped object.

--

___
Python tracker 
<https://bugs.python.org/issue39966>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39966] mock 3.9 bug: Wrapped objects without __bool__ raise exception

[Avram]

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 tracker 
<https://bugs.python.org/issue39966>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39966] mock 3.9 bug: Wrapped objects without __bool__ raise exception

[Avram]

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 and earlier, but fails in 3.9

It seems the goal was to be able to access dunder methods for wrapped objects. 
Before this change __bool__ wasn't actually being checked, but was forced to 
True, which works for basic existence tests. The new code method._mock_wraps = 
getattr(mock._mock_wraps, name) has no fallthrough in case the attribute isn't 
there such as the case with __bool__ on sys.stdout.

--
components: Library (Lib)
messages: 364222
nosy: Darragh Bailey, anthonypjshaw, aviso, cjw296, lisroach, mariocj89, 
michael.foord, pconnell, r.david.murray, rbcollins, xtreak
priority: normal
severity: normal
status: open
title: mock 3.9 bug: Wrapped objects without __bool__ raise exception
type: behavior
versions: Python 3.9

___
Python tracker 
<https://bugs.python.org/issue39966>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30962] Add caching to logging.Logger.isEnabledFor()

[Avram]

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 anywhere in the ancestry.

--

___
Python tracker 
<http://bugs.python.org/issue30962>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30962] Add caching to logging.Logger.isEnabledFor()

[Avram]

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 half the current time.

Benchmark code is in the referenced pull request

--
components: Library (Lib)
messages: 298612
nosy: aviso
priority: normal
pull_requests: 2811
severity: normal
status: open
title: Add caching to logging.Logger.isEnabledFor()
type: performance
versions: Python 3.7

___
Python tracker 
<http://bugs.python.org/issue30962>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com