On Tue, Dec 13, 2011 at 11:47 PM, Eelco <hoogendoorn.ee...@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). Any name may be bound to any value - or if you like, any variable can contain any type. Same applies to argument passing - you can even take an unbound method and call it with some completely different type of object as its first parameter. (I can't think of ANY situation in which this would not be insanely confusing, tbh.) When you gather a function's arguments into a tuple, list, or any other such container object, what you're doing is constructing another object and stuffing it with references to the original arguments. That involves building a new object, where otherwise you simply bind the arguments' names to the original objects directly. Now, it is perfectly conceivable to have designed Python to _always_ pass tuples around. Instead of a set of arguments, you just always pass exactly one tuple to a function, and that function figures out what to do with the args internally. If that's the way the language is built, then it is the _caller_, not the callee, who builds that tuple; and we still have the same consideration if we want a list instead. 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. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
