all() is slow?

Devin Jeanpierre jeanpierreda at gmail.com
Thu Nov 10 23:35:32 EST 2011


> You will notice both of them keep the field name validation.

There are lots of reasons for that to be the case. To me, the most
likely one just seems to be that you don't want to remove more than
necessary when changing the way something works under the hood -- both
for compatibility reasons, and because you want the patch to get
accepted and want the least number of objectionable changes. I guess
you disagree.

> 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?

I just don't believe this reasoning is what happened, I suppose. And
there's no way for you to convince me, or me to convince you, without
R. Hettinger stepping in here and verifying one side of the story.
This is subjective supposition, and that was supposed to be my most
objective opposition.

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, just for concerns that you have that users might not share --
especially when it's valid everywhere else that the concept shows up.
It seems totally inconsistent with the attitude expressed above (by
you!) towards exec, which is that it's ok to be cautious of something,
but something else to forbid it outright.

Of course, as I said before, I don't agree with core python developers
on lots of things. I guess this is just another thing I just don't
understand.

Devin

On Thu, Nov 10, 2011 at 6:07 PM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> On Thu, 10 Nov 2011 15:37:05 -0500, Devin Jeanpierre wrote:
>
>>> '--' not being allowed for a name has *nothing* to do with exec, and
>>> everything to do with `--` not being a valid Python identifier.
>>
>> The only reason valid python identifiers come into it at all is because
>> they get pasted into a string where identifiers would go, and that
>> string is passed to exec().
>
> 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?
>
> You could remove the validation, allowing users to pass invalid field
> names, but that would be a lousy API. If you want field names that aren't
> valid identifiers, the right solution is a dict, not attributes.
>
> Here's a re-implementation using a metaclass:
>
> http://pastebin.com/AkG1gbGC
>
> and a diff from the Python bug tracker removing exec from namedtuple:
>
> http://bugs.python.org/file11608/new_namedtuples.diff
>
>
> You will notice both of them keep the field name validation.
>
>
> --
> Steven
> --
> http://mail.python.org/mailman/listinfo/python-list
>



More information about the Python-list mailing list