Pythonification of the asterisk-based collection packing/unpacking syntax

[Eelco]

On Dec 18, 5:52 am, buck <workithar... at gmail.com> wrote:
> I like the spirit of this. Let's look at your examples.

Glad to see an actual on-topic reply; thanks.

> > Examples of use:
> >     head, tail::tuple = ::sequence
> >     def foo(args::list, kwargs::dict): pass
> >     foo(::args, ::kwargs)
>
> My initial reaction was "nonono!", but this is simply because of the ugliness. The double-colon is very visually busy.

I would have preferred the single colon, but its taken. But exactly
this syntax is used in other languages (for what that is worth...)

> I find that your second example is inconsistent with the others. If we say that the variable-name is always on the right-hand-side, we get:
>
> >     def foo(list::args, dict::kwargs): pass
>
> This nicely mirrors other languages (such as in your C# example:  "float foo") as well as the old python behavior (prefixing variables with */** to modify the assignment).

The link in my OP has the BDFL discussing type constraints; he also
prefers identifier:type. Many modern languages have something similar.
How is my second example inconsistent?

> As for the separator, let's examine the available ascii punctuation. Excluding valid variable characters, whitespace, and operators, we have:
>
> ! -- ok.
> " -- can't use this. Would look like a string.
> # -- no. Would looks like a comment.
> $ -- ok.
> ' -- no. Would look like a string.
> ( -- no. Would look like a function.
> ) -- no. Would look like ... bad syntax.
> , -- no. Would indicate a separate item in the variable list.
> . -- no. Would look like an attribute.
> : -- ok, maybe. Seems confusing in a colon-terminated statement.
> ; -- no, just no.
> ? -- ok.
> @ -- ok.
> [ -- no. Would look like indexing.
> ] -- no.
> ` -- no. Would look like a string?
> { -- too strange} -- too strange
>
> ~ -- ok.
>
> That leaves these. Which one looks least strange?
>
> float ! x = 1
> float $ x = 1
> float ? x = 1
> float @ x = 1
>
> The last one looks decorator-ish, but maybe that's proper. The implementation of this would be quite decorator-like: take the "normal" value of x, pass it through the indicated function, assign that value back to x.

I dont think thats too proper an analogy. The type constraint does not
just coerce the content that is bound to the variable, it influences
the semantics of the whole statement; so insofar there is a suggested
relation with decorators, id rather not have it.


>
> 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.

Yes, maximum backwards compatibility would be great.