> 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.pyt...@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 > -- http://mail.python.org/mailman/listinfo/python-list
