On Sat, 17 Dec 2011 23:33:27 -0600, Evan Driscoll wrote: > This would suggest perhaps some keywords might be called for instead of > operators.
The barrier to new keywords in Python is very high. Not going to happen for something that already has perfectly good syntax already familiar to Python and Ruby programmers. Might else well try to get C and Java to stop using "..." (ellipses). > In the grand scheme of things the argument packing and > unpacking are not *all* that common, so I don't think the syntactic > burden would be immense. The burden is that you complicate the compiler and reduce the pool of useful names available to the programmer. To be useful, the keywords need to be short, meaningful and memorable -- which means they're already used in code, which you will break needlessly. With operators that otherwise would be illegal, the programmer doesn't need to learn about varargs until they need to. With keywords, the programmer needs to learn "you can't use varargs or kwargs as variable names" practically from day 1. > But then you could also say > def foo(varargs(list) l, kwargs(dict) d) So you're not just adding keywords, you're adding new syntax: something which looks like a function call, but isn't a function call. Another feature which the programmer has to learn just to be able to read Python source code -- and one which almost certainly is going to clash with function annotations as people start using them. I'm going to pose the same question to you I have already posed to Eelco: in your proposal, what happens if the caller has shadowed the list built- in? Does argument l become a built-in list, or does it become whatever type list is currently bound to? Some more questions: Can varargs accepted arbitrary callables, or only a fixed set of known types? How does this differ from what can be done with annotations? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
