<div class="gmail_quote">On Sun, Nov 29, 2009 at 9:59 PM, Carl Banks <span dir="ltr"><<a href="mailto:pavlovevidence@gmail.com">pavlovevidence@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Another thing that can be determined through common sense is that if<br>
you have object that you are calling getattr and setattr on so much<br>
that you think you need special syntax, you should have been using a<br>
dict.<br></blockquote><div><br>(Re-send; original was sent to the wrong address. I--I mean, Gmail--sent it to the wrong address by mistake. :P )<br><br>While you were writing this and your previous reply I was working on a
response that kind of covers what you were talking about, but I'm going
to say something anyway.<br><br>Well, yes, the names would have to be
determined at run time. That's what getattr and setattr do, except that
that do it in the context of an object rather than the local scope.
However, I was under the impression that python's mechanism for looking
up local names was the same as the mechanism used to look up attributes
because names and attributes seem to function pretty much the same way.
This I assumed because of the functionality of the locals() and
globals() functions, which seem to act like the __dict__ attribute on
objects except that the work on the current scope. Also, there is the
__builtins__ module, which actually _is_ an object, but its names can
be accessed in the same way as locals and globals.<br>
<br>I had considered the possibility of a peformance hit, however I
didn't anticipate that it would be all that much. Not that it matters,
but how much are we talking? 10% ? 50% ? In any case, I'm not really an
expert on Python's internal constructions, but because of this
discussion I'm considering taking some time to learn them.<br>
<br><br>
Python is unique compared to several other languages in that it makes a
distinction between "items" and "attributes". Some languages, like
JavaScript and Lua, do not make this distinction. They leave it to the
programmer to access members of an object either as an item or as an
attribute. I don't think there is necessarily anything wrong with this,
nor do I think there is anything wrong with Python's separation.<br><br>That
said, just because you can use the proposed syntax to use an object in
the same way as a dict does not mean that it works the other way
around. I'm not talking about the allowance of any specific object to
have any number of pairings between arbitrary keys and values. That's
what dicts are for, and that's what indexing syntax implies.<br>
<br>Rather, I'm talking about specific, concrete variables which
objects are expected (though not technically required) to have bound to
them according to how the object is intended to be used. (That's
probably not the best definition of an attribute, but it's the best I
can think of ATM.)<br>
<br>I'm not trying to discard Python's distinction between items and
attributes, but I don't want to be limited by it due to mere
syntactical constraints, either.<br><br>May the Penguin in the sky bless your every subroutine,<br>
<br>Brad Harms <br></div></div>