<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Mar 3, 2011, at 4:19 PM, Greg Ewing wrote:</div><div><blockquote type="cite">. For example, currently you write</blockquote></div><blockquote type="cite"><div><br> Fred = namedtuple('Fred', 'x y z')<br><br>This would become<br><br> @namedtuple<br> Fred = 'x y z'<br></div></blockquote></div><div><br></div><div>How are tuples handled?</div><div><br></div><div> @deco</div><div> C = a, b, c</div><div><br></div><div>Is this C('C', a, b, c) or C('C', (a, b, c))?</div><div><br></div><div>All in all this seems like too much firepower (a language syntax change) for too little benefit (how much do we really care that 'C' got typed twice?).</div><div><br></div><div>If there were going to be only one syntax change for Python 3.3, why not use it for something that adds a lot more expressive power:</div><div><br></div><div> x = a!name # x = getattr(a, name)</div><div><br></div><div>That bit of syntactic sugar might greatly expand our minds when it comes to dynamically creating and accessing attributes. Almost any syntax would do: a::name a$name a[[name]] etc. Using external data to build classes/structs on the fly is under-utlized technique in Python:</div><div><br></div><div> # create a new sub-category</div><div> k = type(kind, parents, {})</div><div> for trait, value in traits.items():</div><div> k$trait = value</div><div><br></div><div> # access some trait in the hierarchy of traits</div><div> print(k$trait)</div><div><br></div><div>Another expressive bit a syntax would be for a way to do a def into a target namespace. Currently, to implement prototype OO, we need to do something like this:</div><div><br></div><div><div>o = Object() # base prototype OO class</div><div>o.balance = 0 # populate the prototype instance</div><div><a href="http://o.name/">o.name</a> = 'empty'</div><div>def deposit(self, amt):</div><div> self.balance += amt</div><div>o.deposit = deposit</div><div>del deposit</div><div>p = o.clone() # make a new account</div><div><a href="http://p.name/">p.name</a> = 'john q public'</div><div>def custom_rule():</div><div> if self.balance < 500:</div><div> notify_low_balance(self)</div></div><div>p.custom_rule = custom_rule</div><div>del custom_rule</div><div><br></div><div>Wouldn't it be better to write directly into a target namespace?</div><div><br></div><div><div>o = Object() # base prototype OO class</div><div>o.balance = 0 # prototype instance</div><div><a href="http://o.name/">o.name</a> = 'empty'</div><div>def o.deposit(self, amt):</div><div> self.balance += amt</div><div>p = o.clone() # make a new account</div><div><a href="http://p.name/">p.name</a> = 'john q public'</div><div>def p.custom_rule():</div><div> if self.balance < 500:</div><div> notify_low_balance(self)</div></div><div><br></div><div>This would also be useful for handler dicts and dispatch dicts :</div><div><br></div><div>actions = {}</div><div>def actions.shoot():</div><div> print('Fire!')</div><div>def actions:retreat():</div><div> print('Run away!)</div><div>for action in commands:</div><div> actions[action]</div><div> history.update(action)</div><div> ...</div><div><br></div><div>I think if a new syntax gets added, it should do something bold and expressive. I don't think that assignment decorators add a significant new capability. AFAICT, it just saves a few characters but doesn't change the way we think or work. If someone were proposing a C macro that did exactly the same thing, someone else would complain that it was cryptic, had too little benefit, and hid what was really going-on behind a layer of abstraction.</div><div><br></div><div><br></div><div>Raymond</div></body></html>