Ralf W. Grosse-Kunstleve wrote:
I know enhancing the syntax is work, but shouldn't a syntax leading to less code clutter be the higher value? IMO a long-term gain counts for much more than avoiding a one-time investment implementing a useful feature. Take, for example, the syntax enhancement supporting "import foo as bar". I could just as easily write:
import foo bar = foo del foo
"A syntax change is wholly unnecessary." Why was it important enough anyway? It was a good enhancement because it is clearly more expressive and reduces clutter.
In my experience the self.x=x; self.y=y etc. problem arises much more often than the problem solved by "import foo as bar". IMO a *built-in* solution is much more important in practice. Why does everybody have to reinvent the adopt_init_args/initialize wheel, or have to sheepishly type self.x=x...?
Actually, this reminds me of a recent suggestion (from AMK?) about being able to get at both the packed and unpacked form of an argument via: def f(arg as (a, b, c)): print arg print c, b, a Then f([1, 2, 3]) would print: [1, 2, 3] 3 2 1 If the right hand side of 'as' permitted the same forms as are going to be permitted for the 'as' clause in 'with' statements, then Ralf's situation could be handled via: def __init__(self as s, x as s.x, y as s.y, z as s.z): pass Essentially, it allows arguments to be given two names - a public name (before the 'as', used for keyword arguments), and a private name (after the 'as', not used for keyword arguments, allows easy shorthand aliasing of self, unpacking of tuple arguments, and easy assignment of instance variables). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.blogspot.com