[issue44981] wildcard imports should normalise names in `__all__`

[Steven D'Aprano]

Steven D'Aprano <steve+python at pearwood.info> added the comment:

On Mon, Aug 23, 2021 at 05:42:59PM +0000, Serhiy Storchaka wrote:
> 
> Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:
> 
> Should getattr() normalize attribute name? If no, it will produce 
> surprises further along the way. If yes, it will add significant 
> overhead.

Good point.

In pure Python, normalising the string in getattr does have significant 
cost, about 125% slower on my computer using 3.9:

    >>> from functools import partial
    >>> import unicodedata
    >>> normalise = partial(unicodedata.normalize, "NFKC")
    >>> def mygetattr(obj, name, _normalise=normalise, _getattr=getattr):
    ...     return _getattr(obj, _normalise(name))
    ... 
    >>> t1 = Timer('getattr([], "reverse")')
    >>> t2 = Timer('mygetattr([], "reverse")', setup='from __main__ import mygetattr')
    >>> 
    >>> min(t1.repeat(repeat=7))
    0.08972279605222866
    >>> min(t2.repeat(repeat=7))
    0.20272555301198736
    >>> (0.20272555301198736-0.08972279605222866)/0.08972279605222866
    1.2594653971102117

But for ASCII strings at least, I think there is an opportunity to avoid 
that cost entirely. See #44987.

> Even star-import can get significant impact.

I'm less worried about that for three reasons:

1. It only affects star-import, which is not "best practice", so only a 
small number of scripts will be affected.

2. In the most overwhelming common case, you do any star-imports once, 
at the beginning of the module, not repeatedly. Star-imports will not be 
part of a tight, performance critical loop. So it is a one-off cost.

3. The cost of an import is a lot more than just the getattr, so any 
normalisation cost is a correspondingly smaller part of the total.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44981>
_______________________________________