Attributes which aren't valid python identifiers

Question

The usual method of attribute access requires attribute names to be valid python identifiers.

But attributes don't have to be valid python identifiers:

>>> class Thing:
...     def __init__(self):
...         setattr(self, '0potato', 123)
...         
>>> t = Thing()
>>> Thing.__getattribute__(t, '0potato')
123
>>> getattr(t, '0potato')
123

Of course, t.0potato remains a SyntaxError, but the attribute is there nonetheless:

>>> vars(t)
{'0potato': 123}

What is the reason for this being permissable? Is there really any valid use-case for attributes with spaces, empty string, python reserved keywords etc? I thought the reason was that attributes were just keys in the object/namespace dict, but this makes no sense because other objects which are valid dict keys are not allowed:

>>> setattr(t, ('tuple',), 321)
TypeError: attribute name must be string, not 'tuple'

Answer 1

So, to answer the use case question, looking at the reasoning behind how Python works in the references from the comments above, we can infer some of the situations that might make this Pythonic quirk useful.

1. You want an object to have an attribute that cannot be accessed with dot notation, say, to protect it from the naive user. (Quoting Guido: "some people might use this to hide state they don't want accessible using regular attribute notation (x.foo)". Of course, he goes on to say, "but that feels like abuse of the namespace to me, and there are plenty of other ways to manage such state.")
2. You want an object's attribute names to correspond to external data over which you have no control. Thus, you have to be able to use whatever strings appear in the external data as an attribute name even if it matches a Python reserved word or contains embedded spaces or dashes, etc.

Answer 2

The details from a comment on the post fully answer this question, so I'm posting it as an answer:

Guido says:

...it is a feature that you can use any arbitrary string with getattr() and setattr(). However these functions should (and do!) reject non-strings.

Possible use-cases include hiding attributes from regular dotted access, and making attributes in correspondence with external data sources (which may clash with Python keywords). So, the argument seems to be there's simply no good reason to forbid it.

As for a reason to disallow non-strings, this seems to be a sensible restriction which is ensuring greater performance of the implementation:

Although Python's dicts already have some string-only optimizations -- they just dynamically adapt to a more generic and slightly slower approach once the first non-key string shows up.