Issue 13793: hasattr, delattr, getattr fail with unnormalized names (original) (raw)

The documentation for hasattr, getattr, and delattr state that they are equivalent to object.attribute access; this isn't quite true, because object.attribute uses a NFKC-normalized version of the string as only the secondary location, while hasattr, getattr, and delattr (assuming an object rather than an Identifier or string) don't seem to do the normalization at all.

I think the simplest fix would be to normalize and retry when hasattr, getattr, and delattr fail with a string, but I'm not sure that normalization shouldn't be the only string tried.

o.º Traceback (most recent call last): File "<pyshell#820>", line 1, in o.º AttributeError: 'Object' object has no attribute 'o' o.o Traceback (most recent call last): File "<pyshell#821>", line 1, in o.o AttributeError: 'Object' object has no attribute 'o' o.º=[] hasattr(o, "º") False getattr(o, "º") Traceback (most recent call last): File "<pyshell#824>", line 1, in getattr(o, "º") AttributeError: 'Object' object has no attribute 'º' delattr(o, "º") Traceback (most recent call last): File "<pyshell#825>", line 1, in delattr(o, "º") AttributeError: º o.º [] o.º is o.o True o.o [] del o.º o.o Traceback (most recent call last): File "<pyshell#830>", line 1, in o.o AttributeError: 'Object' object has no attribute 'o'

o.º = 5 hasattr(o, "º") False hasattr(o, "o") True hasattr(o, "o") True o.º 5 delattr(o, "o") o.º

Why is normalization in getattr unacceptable? I won't pretend to like it, but the difference between two canonically equal strings really is (by definition) just a representational issue.

Would it be OK to normalize in object's own implementation, so that custom classes could avoid the normalization, but it would happen by default?