all() is slow?

[Devin Jeanpierre]

> which implies that getattr(x, 'a!b') should be equivalent to x.a!b

No, it does not. The documentation states equivalence for two
particular values, and there is no way to deduce truth for all cases
from that. In fact, if it _was_ trying to say it was true for any
attribute value, then your example would be proof that the
documentation is incorrect, since CPython breaks that equivalence.

Devin

On Fri, Nov 11, 2011 at 8:18 PM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> On Thu, 10 Nov 2011 23:35:32 -0500, Devin Jeanpierre wrote:
>
>>> That is patently untrue. If you were implementing namedtuple without
>>> exec, you would still (or at least you *should*) prevent the user from
>>> passing invalid identifiers as attribute names. What's the point of
>>> allowing attribute names you can't actually *use* as attribute names?
>>
>> Then why doesn't Python do this anywhere else? e.g. why can I
>> setattr(obj, 'a#b') when obj is any other mutable type?
>
> That is implementation-specific behaviour and not documented behaviour
> for Python. If you try it in (say) IronPython or Jython, you may or may
> not see the same behaviour.
>
> The docs for getattr state:
>
>    getattr(x, 'foobar') is equivalent to x.foobar
>
>
> which implies that getattr(x, 'a!b') should be equivalent to x.a!b which
> will give a syntax error. The fact that CPython does less validation is
> arguably a bug and not something that you should rely on: it is *not* a
> promise of the language.
>
> As Terry Reedy already mentioned, the namespace used in classes and
> instances are ordinary generic dicts, which don't perform any name
> validation. That's done for speed. Other implementations may use
> namespaces that enforce legal names for attributes, and __slots__ already
> does:
>
>>>> class X(object):
> ...     __slots__ = ['a', 'b!']
> ...
> Traceback (most recent call last):
>  File "<stdin>", line 1, in <module>
> TypeError: Error when calling the metaclass bases
>    __slots__ must be identifiers
>
>
> [...]
>> To go off on another tangent, though, I don't really understand how you
>> guys can think this is reasonable, though. I don't get this philosophy
>> of restricting inputs that would otherwise be perfectly valid
>
> But they aren't perfectly valid. They are invalid inputs. Just because
> getattr and setattr in CPython allow you to create attributes with
> invalid names doesn't mean that everything else should be equally as
> slack.
>
>
> --
> Steven
> --
> http://mail.python.org/mailman/listinfo/python-list
>