[Python-Dev] New syntax for 'dynamic' attribute access

[Calvin Spealman]

I'll take this opportunity to pipe in with a response, since Guido
summed up the many issues nicely and its a good bouncing point to
mention my own thoughts.

On 2/12/07, Guido van Rossum <guido at python.org> wrote:
> My perspective:
>
> - There's a lot of support for the basic idea, and only a few
> naysayers, so let's keep looking for a syntax that works.
>
> - There's near-universal dislike for the two-arg form, so let's drop
> that part of the proposal.
>
> - I can't recall that x.[y] has been proposed yet, but thinking about
> it, that actually makes more sense than x.(y). (In fact, in JavaScript
> you can write x[y] to the same effect. I wouldn't discount the JS
> example; JS is probably closer to Python than almost any other
> language currently in existence except for Boo, and JS has
> successfully borrowed from Python.)

I'll second that. The JS case is valuable and a good representation of
the mindset behind using foo.[bar]

> - I'm not too concerned by the '.' being such a small character with
> this new proposal. x[y] is a lot less common than x(y), so you'll look
> twice when you think you see x[y] and it doesn't make sense, and then
> you'll notice it's really x.[y], which you either know or don't, and
> in the latter case you'll be looking it up or asking around.

I definitely see the downside of using the nearly invisible . here.
Looking like dirt on the screen, being misunderstood, deleted because
someone thought it was a typo, etc. could all be problems. I am not
convinced they will be problems, only that they could.


Now, do we need a more readable attribute deference or is there some
optimizational need to make a syntax specifically for it? Why can't we
just wrap the object in question with some attribute lookup type?

attr(o)[methodname]() vs o.[methodname]()

I think if you read those two, at a quick glance the first is a lot
more readable than the second. It also has the advantage of not
modifying the language syntax, or introducing nearly as much new code.

-- 
Read my blog! I depend on your acceptance of my opinion! I am interesting!
http://ironfroggy-code.blogspot.com/