Feature request: String-inferred names

[Lie Ryan]

On 11/29/2009 12:22 PM, The Music Guy wrote:
> 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.

And we don't want a second flood of users asking about foo.$bar.

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

You're absolutely right, and I have *never needed* to use the plain 
getattr/setattr/delattr enough to even bother considering a syntax that 
already looks ugly at first sight. For @decorators, everyone used it 
*often enough* BEFORE it turned into a syntax that the ugly syntax is 
justified and become "acceptable". If you can find a syntax that doesn't 
look ugly at first sight +0, fine by me; otherwise -1, I don't want to 
be forced to read an ugly syntax for a feature that I don't use often 
enough. It's not just the syntax, the necessity+syntax don't add up well.

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

In so far, your definition of adjusting only means something around 
"[a-zA-Z0-9_]+\.[^a-zA-Z0-9_][<{(\[]?[a-zA-Z0-9_]+[>})\]]?"

that class of syntax is ugly; some are more acceptable (e.g. obj.[arg]) 
the old thread have spawned better alternatives than that class of syntax.

> As for my specific use case, it's somewhat difficult to explain.

You know that:
If the implementation is hard to explain it's a bad idea.
                                          -- Zen of Python --

right?

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

Do you mean something like this?

class A(object):
     @property
     def the_b(self):
         return self._b
     @the_b
     def the_b(self, new_b):
         self._b = new_b
         self._b._a = self

class B(object):
     @property
     def the_a(self):
         return self._a
     @the_a
     def the_a(self, new_a):
         self._a = new_a
         self._a._b = self

am I getting you right? If not, please elaborate and give an example of 
what you actually meant.