Feature request: String-inferred names

[Brad Harms]

On Sun, Nov 29, 2009 at 9:59 PM, Carl Banks <pavlovevidence at gmail.com>wrote:

> Another thing that can be determined through common sense is that if
> you have object that you are calling getattr and setattr on so much
> that you think you need special syntax, you should have been using a
> dict.
>

(Re-send; original was sent to the wrong address. I--I mean, Gmail--sent it
to the wrong address by mistake. :P )

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.

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.

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.


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.

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.

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.)

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.

May the Penguin in the sky bless your every subroutine,

Brad Harms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20091129/f201404b/attachment.html>