Feature request: String-inferred names
lie.1296 at gmail.com
Mon Nov 30 02:49:40 CET 2009
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
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
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
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 --
> 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?
def the_b(self, new_b):
self._b = new_b
self._b._a = self
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.
More information about the Python-list