Pythonification of the asterisk-based collection packing/unpacking syntax

[Steven D'Aprano]

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