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.
--
http://mail.python.org/mailman/listinfo/python-list
