<br><br><div class="gmail_quote">On Sun, Nov 29, 2009 at 7:49 PM, Lie Ryan <span dir="ltr"><<a href="mailto:lie.1296@gmail.com">lie.1296@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On 11/29/2009 12:22 PM, The Music Guy wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
When I first started seeing @ show up in Python code, I said "what the<br>
heck is that? It looks so weird and _ugly_.I would never try to mess<br>
with that." But I started seeing it more and more, so I asked #python<br>
what it was. They told me about decorators, so I looked it up in the<br>
docs, and I thought the idea was interesting. It took me a while to<br>
figure out exactly how they worked--and judging from messages I've<br>
seen in #python a number of people have the same trouble understanding<br>
them.<br>
</blockquote>
<br></div>
And we don't want a second flood of users asking about foo.$bar.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
My point is that any particular syntax would look ugly to you only<br>
because you haven't seen it in use enough, and haven't used it enough<br>
yourself.<br>
</blockquote>
<br></div>
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.<div class="im">
<br>
<br>
> But of course you haven't--it's not currently a valid<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
syntax. However, the ugliness would seem to go away after the syntax<br>
had been in use for a while. And again, the EXACT syntax of the<br>
feature can be adjusted until its "just right".<br>
</blockquote>
<br></div>
In so far, your definition of adjusting only means something around "[a-zA-Z0-9_]+\.[^a-zA-Z0-9_][<{(\[]?[a-zA-Z0-9_]+[>})\]]?" </blockquote><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.<br><div class="im"></div> </blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
As for my specific use case, it's somewhat difficult to explain.<br>
</blockquote>
<br></div>
You know that:<br>
If the implementation is hard to explain it's a bad idea.<br>
-- Zen of Python --<br>
<br>
right?<div class="im"><br>
<br>
> The<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
general idea was to isolate a pattern that I spotted repeated in<br>
several unrelated parts of my project. The pattern manifested itself<br>
as a set of 4-5 methods and/or properties on a class whose objects<br>
were designed to work in conjunction with other objects that fit a<br>
particular behavior. These other objects had methods and properties<br>
that were designed to interact with the first type of object in a<br>
similar but--how should I say--"inverted" fashion.<br>
</blockquote>
<br></div>
Do you mean something like this?<br>
<br>
class A(object):<br>
@property<br>
def the_b(self):<br>
return self._b<br>
@the_b<br>
def the_b(self, new_b):<br>
self._b = new_b<br>
self._b._a = self<br>
<br>
class B(object):<br>
@property<br>
def the_a(self):<br>
return self._a<br>
@the_a<br>
def the_a(self, new_a):<br>
self._a = new_a<br>
self._a._b = self<br>
<br>
am I getting you right? If not, please elaborate and give an example of what you actually meant.<div><div></div><div class="h5"><br>
-- <br>
<a href="http://mail.python.org/mailman/listinfo/python-list" target="_blank">http://mail.python.org/mailman/listinfo/python-list</a><br>
</div></div></blockquote></div><br><br>I understand that in all likelyhood this feature won't be added to Python anytime soon, if at all. But I'd like to continue this discussion anyway; it's been enlightening for me. Even though I don't agree with the views of some of the people who've replied, I like the insight. And anyway, I think that if the syntax were already present, people would feel a lot more positively about it; it's the idea of adding it in so late in the game that people seem to have a problem with for the most part.<br>
<br>
It doesn't seem like anybody besides inhahe has actually realized that
my proposition is actually different than PEP 363 in a subtle but
crucial way. It's not _literally_ a shorthand for accessing the *attr
functions; that's just the way I originally assumed it would be used
most often. However, I have since realized that the syntax is more powerful than I originally thought: ANYWHERE that a name appeared--this includes function names,
class names, function parameters, possibly even module names--could be
replaced by an expression that would be evaluated to the name. That
makes the use of any kind of brackets, except maybe <angle
brackets>, bad options, as it would conflict with [lists,] {dicts,} (tuples,) or generic parenthesized (expressions). There must be a unique indicator of some
kind, something that isn't already in use by the interpreter. That way there is no possible way that it could get confused with another syntactical construct.<br>
<br>
So you could do something like this:<br>
<br><br>
def class_factory(this, that)<br> get_that = "get_"+that<br> set_that = "set_"+that<br>
_that = "_" + that<br>
<br>
class $this (object):<br>
<br>
def __init__(self, $that = None):<br>
self.$_that = $that<br>
<br>
def $get_that (self):<br> return self.$_that<br><br> def $set_that (self, $that):<br> self.$_that = $that<br><br> $that = property($get_that, $set_that)<br><br> return $this<br>
<br><br>Compare the code above with this approximation that uses the current syntax rules:<br><br><br>def class_factory(this, that):<br> get_that_name = "get_"+that<br>
set_that_name = "set_"+that<br> _that = "_" + that<br><br> class This(object):<br><br> def __init__(self, that = None):<br> setattr(self, _that, that)<br>
<br> This.__name__ = this<br><br> def get_that(self, that):<br>
return getattr(self, _that)<br>
get_that.__name__ = get_that_name<br> setattr(This, get_that_name, get_that.__get__(None, This))<br>
<br>
def set_that(self, that):<br>
setattr(self, _that, that)<br> set_that.__name__ = set_that_name<br> setattr(This, set_that_name, set_that.__get__(None, This))<br><br> setattr(This, that, property(get_that, set_that))<br>
<br> return This<br><br><br>Given either of the two class factories above, the following can be done:<br><br><br>Spam = new_foo_class("Spam", "eggs")<br>
Eggs = new_foo_class("Eggs", "spam")<br>
<br>
myspam = Spam()<br>
myeggs = Eggs()<br>
<br>
myeggs.spam = myspam<br>
myspam.set_eggs( myeggs )<br>
<br>
print myspam.get_eggs() # prints "<Eggs object at ...>"<br>
print myeggs._spam # prints "<Spam object at ...>"<br><br><br>However, the following can only be done using the first example:<br><br><br>myspam.set_eggs( eggs = myeggs )<br><br><br>For the second example, it would have to be this:<br>
<br><br>myspam.set_eggs( that = myeggs )<br><br><br>The reason is that the parameter names for the first example are determined dynamically, which I don't think python allows you to do currently. The closest thing is **kwargs, but that's less readable than an actual parameter name.<br>
<br>That was a relatively simple example; classes as simple as the ones generated by the It is more likely that the class generation could would appear in a metaclass's class constructor or decorator function, and there would be more than just the three attributes given.<br>