Feature request: String-inferred names

[The Music Guy]

On Nov 28, 6:10 am, Lie Ryan <lie.1... at gmail.com> wrote:
> On 11/28/2009 10:38 PM, The Music Guy wrote:
>
> >> If you use it a lot, it is likely 1) you have abused class syntax for
> >> what should have been a dict or 2) what you need is to override
> >> __getattr__/__getattribute__ and __setattr__
>
> > Oh boy...here we go. :|
> > <sniprant>
>
> ok, then what's your use case, AFAICT in the discussion here and
> previous ones, nobody has yet described a realistic and compelling
> situation where setattr/getattr is the best solution. That's why the
> discussion tended to end with "not used frequently enough"; simply
> because nobody can turn up with a use case to justify a new syntax,
> especially since all the proposed syntax are ugly (the most acceptable
> one, for me, is obj.[foo], still ugly but not as ugly as the others).

Alright, I'm not sure if my last message about this came through, so
I'm going to assume it didn't.

When I first started seeing @ show up in Python code, I said "what the
heck is that? It looks so weird and _ugly_. I would never try to mess
with that." But I started seeing it more and more, so I asked #python
what it was. They told me about decorators, so I looked it up in the
docs, and I thought the idea was interesting. It took me a while to
figure out exactly how they worked--and judging from messages I've
seen in #python a number of people have the same trouble understanding
them.

My point is that any particular syntax would look ugly to you only
because you haven't seen it in use enough, and haven't used it enough
yourself. But of course you haven't--it's not currently a valid
syntax. However, the ugliness would seem to go away after the syntax
had been in use for a while. And again, the EXACT syntax of the
feature can be adjusted until its "just right".

As for my specific use case, it's somewhat difficult to explain. The
general idea was to isolate a pattern that I spotted repeated in
several unrelated parts of my project. The pattern manifested itself
as a set of 4-5 methods and/or properties on a class whose objects
were designed to work in conjunction with other objects that fit a
particular behavior. These other objects had methods and properties
that were designed to interact with the first type of object in a
similar but--how should I say--"inverted" fashion.

This pattern showed up in many different classes throughout the
project, and not only that, but the code was very similar. I decided
to try to eliminate some of the code redundancy by creating a base
class for all the classes to derive from. That didn't worked out okay
for some things, but not for others. I can't remember the exact
details of the problem at this point, but I believe it had to do with
the keying/indexing protocol (ie. __getitem__, __setitem__, etc.). I
decided to keep the base class (and have since extended it), but
decided that it wasn't enough--that's when I decided to try
metaclassing. After some work I managed to recreate the object-to-
object relationship pattern that kept showing up everywhere, but in a
generic way that allowed for the names of methods and properties that
composed the pattern to vary in name and in the names that they
referenced from other objects. The code worked very well, and allowed
for the pattern to be added to any class by using a single, short line
of code (something along the lines of __class_attr = { key: value }).
Not only that, but the metaclass code itself was comprised of less
than a screenful of code after docstrings and comments had been
removed. However, the code was (and still is) very difficult to follow
simply because of the way getters and setters had to be used to
generate the methods and properties.

P.s. Ben Finney, I appreciate your response, and I will get back to
you,
but I want to make sure I reply under the right circumstances or I'll
end up putting my foot in my mouth. ^_^