Pythonification of the asterisk-based collection packing/unpacking syntax

[Eelco]

On Dec 18, 6:33 am, Evan Driscoll <edrisc... at wisc.edu> wrote:
> On 12/17/2011 22:52, buck wrote:> Try these on for size.
>
> >      head, @tuple tail = sequence
> >      def foo(@list args, @dict kwargs): pass
> >      foo(@args, @kwargs)
>
> > For backward compatibility, we could say that the unary * is identical to @list and unary ** is identical to @dict.
>
> I like this idea much more than the original one. In addition to the
> arguments buck puts forth, which I find compelling, I have one more: you
> go to great length to say "this isn't really type checking in any sense"
> (which is true)... but then you go forth and pick a syntax that looks
> almost exactly like how you name types in many languages! (In fact,
> except for the fact that it's inline, the 'object :: type' syntax is
> *exactly* how you name types in Haskell.)

No, its not type *checking*, its type *declaration*. I tried to go to
great lengths to point that out, but it appears I did not do a very
good job :). Type declaration is exactly what I want, and insofar this
syntax has already found adoptation elsewhere, ill consider that a
plus.

> I have a bigger objection with the general idea, however.It seems very
> strange that you should have to specify types to use it. If the */**
> syntax were removed, that would make the proposed syntax very very
> unusual for Python. I could be missing something, but I can think of any
> other place where you have to name a type except where the type is an
> integral part of what you're trying to do. (I would not say that
> choosing between tuples and lists are an integral part of dealing with
> vararg functions.) If */** were to stick around, I could see 99% of
> users continuing to use them. And then what has the new syntax achieved?

Good point; technically the askeriskes could be kept for backwards
compatibility, but that would break 'there should only be one way to
do it'. Indeed it would be unusual for python to have to explicitly
name a type, but implicitly ** does very much the same. Its just a
cryptic way of saying 'dict please'.

> You can fix this if you don't require the types and just allow the user
> to say "def foo(@args)" and "foo(@args)". Except... that's starting to
> look pretty familiar... (Not to mention if you just omit the type from
> the examples above you need another way to distinguish between args and
> kwargs.)

Yes, one could opt for a syntax where the collection type is optional
and a sensible default is chosen, But to me that would largely defeat
the point; I very much like the added verbosity and explicitness. args-
tuple and kwargs-dict; that just has a much better ring to it than
star-star-kwargs, or whatever other cryptic symbol you use.

> I have one more suggestion.
>
> I do have one more thing to point out, which is that currently the
> Python vararg syntax is very difficult to Google for. In the first pages
> of the four searches matching "python (function)? (star | asterisk)",
> there was just one relevant hit on python.org which wasn't a bug report.
> I certainly remember having a small amount of difficulty figuring out
> what the heck * and ** did the first time I encountered them.
>
> This would suggest perhaps some keywords might be called for instead of
> operators. 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 bigger issue, of course, would be picking
> good words.
>
> This also helps with the issue above. Let's say we'll use 'varargs' and
> 'kwargs', though the latter too well-ingrained in code to steal. (I
> don't want to get too much into the debate over *what* word to choose.
> Also these don't match the 'head, *tail = l' syntax very well.) Then we
> could say:
>   def foo(varargs l, kwargs d):
>       bar(varargs l, kwargs d)
> and varargs would be equivalent to * and kwargs would be equivalent to
> **. But then you could also say
>   def foo(varargs(list) l, kwargs(dict) d)

I agree; I had the same experience. But according to others our
opinion is wrong, and we should just become better at using google.