Verbose and flexible args and kwargs syntax

[Eelco]

On 13 dec, 14:14, Chris Angelico <ros... at gmail.com> wrote:
> On Tue, Dec 13, 2011 at 11:47 PM, Eelco <hoogendoorn.ee... at gmail.com> wrote:
> >> def f(*args) *constructs* a tuple, it
> >> doesn't perform a type-check.
>
> > I am talking about type constraints... A type-check is something
> > along the lines of type(args)==list, a runtime thing and something
> > completely different. I havnt mentioned the latter at all, explicitly
> > or implicitly, as far as im aware.
>
> I'm not sure what you mean by a "type constraint". Here's how I understand such:
>
> float|int foobar; //Declare that the variable 'foobar' is allowed to
> hold a float or an int
> foobar = 3.2; //Legal.
> foobar = 1<<200; //Also legal (a rather large integer value)
> foobar = "hello"; //Not legal
>
> Python doesn't have any such thing (at least, not in-built).

Agreed on what a type constraint is, and that python does not really
have any, unless one counts the current use of asterikses, which are
infact a limited form of type constrait (*tail is not just any object,
but one holding a list, which modifies the semantics of the assignment
statement 'head,*tail=sequence' from a regular tuple unpacking to a
specific form of the more general collection unpacking syntax);

The idea is to enrich this syntax; to add optional and limited type
constraints to python, specifically to enrich collection packing/
unpacking syntax, but perhaps the concept can be further generalized.


> So suppose you can have a user-defined object type instead of
> list/dict. How are you going to write that type's __init__ function?
> Somewhere along the way, you need to take a variable number of
> arguments and bundle them up into a single one... so somewhere, you
> need the interpreter to build it for you. This is going to end up
> exactly the same as just accepting the tuple and then passing that to
> a constructor, like the list example. Keep things transparent and you
> make debugging a LOT easier.

Agreed; for user defined collection types there would not be a
performance benefit over converting a tuple, since this is exactly
what will happen anyway, but for collection types derived from any of
the builtins, python could optimize away the intermediate and
construct the desired collection type directly from the available
information.