On Dec 18, 5:52 am, buck <workithar...@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.
--
http://mail.python.org/mailman/listinfo/python-list
