Feature request: String-inferred names

[The Music Guy]

On Nov 28, 3:07 am, Lie Ryan <lie.1... at gmail.com> wrote:
> On 11/28/2009 3:08 PM, The Music Guy wrote:
>
> > As for your code, I haven't seen it, so it would be hard for me to say
> > exactly how the new syntax would come into play. What I can tell you,
> > however, is that the parts of your code that would use it would
> > probably be easier to read and change to anyone with a firm grasp of
> > the proposed syntax.
>
> Isn't this much easier to read and grasp?
>
> obj.d["my_%s" % foo] += 3
>
> doesn't need new syntax as well.

Actually, that's similar to my backup solution, which is a variant of
the "attrs" class that PEP 363 provides. It does make things easier to
read, but a new syntax would still be better because:

1.) A new syntax would apply to _everything_ as it would be a hook to
the very mechanism that gets the value of a member from an object and
does not rely on an object defining the magic "d" property. I suppose
you could argue that an enhancement could be made to the language that
says that all objects must define the magic "d" (so the builins
"object" and "type" would have to define it). That also has the added
benefit of not conflicting with PEP 3003, which says it is fine to add
new methods (and I would assume properties as well) to existing
classes.

2.) Ben's patch for his proposed syntax generated an aproximate 1%
performance hit for the interpreter overall versus a >40% increase
where code that used the getattr/settattr functions was modified to
use the proposed syntax. The magic "d" MIGHT have a performance
increase over the getattr/setattr functions, but a syntax would still
be significantly faster because there would be less function
dereferencing/calling. For the purposes that I had intended for the
syntax to be used, that would definitely matter.

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

Please listen. In all the time I've spent in the coding community
(that's at least 7 years) and especially since I started paying
attention to the Python community (2 years), I have noticed a trend:
When one coder does something that another cannot understand,
frequently the other will assume the former is not only doing things
wrong, but is doing them _blatantly_ wrong. I have caught myself
making that very assumption many times in the past, and I've tried
hard to build up an immunity against the impulse to make that
assumption. At this point, I don't even believe in such a thing as a
universal "wrong way" and a "right way" to code that applies to every
circumstance. The way to solve a problem depends on the problem. When
it comes to coding, there is not an absolute "right" way or "wrong"
way--unless we're talking about, say, stealing closed source code
without permission, or deliberately coding in a way that will cause
problems for the end user (like causing memory clogs or buffer
overflows and whatnot).

All of this can be determined through common sense. And yet I continue
to see the attitude of "my solution is the ONLY solution to your
problem, and it doesn't matter if I don't even actually understand the
problem." Not everyone does this, but it is a frequent enough
occurence to be worth noting. If I had to pull a number out of my
magic bag, I would say 4 out of 10 resposes have at least a hint of
this attitude, and  2.5/10 where it is very obvious.

But I digress. I've already gone over other possible solutions and the
one I am using seems to fit the bill better than any other yet
presented to me, including the ones you just suggested. In fact, I'm
fairly certain that __getattr__ and friends even apply to the
situation, or if they do, they're certainly inferior alternatives to
the use of getattr/setattr. Not that I'm calling you inferior--I'm
just saying that if you had a better understanding of the problem you
would not see __getatrr__ et al. as parts of a possible solution
because they don't really make logical sense given the circumstances.

...and I have one last thing to say. I feel very strongly that
metaclassing is a fiercely underestimated and largely untapped source
of good coding solutions. I hope that many coders will see this and
help to make it more adoptable by the masses; at present it is seen as
a big, scary beast that is hard to tame and even harder to drive. It
is portrayed as something dangerous that should only be used in
relatively rare situations. I disagree with this view. It is the view
itself which makes it seem so dangerous (in other words, it is self-
perpetuating).

Well, that's about enough yakking for 5:30 in the morning...time to
give my noggin a rest.

-- Brad Harms