On Sat, 17 Dec 2011 06:38:22 -0800, Eelco wrote: > Type constraints: > > In case the asterisk is not used to signal unpacking, but rather to > signal packing, its semantics is essentially that of a type constraint.
"Type constraint" normally refers to type restrictions on *input*: it is a restriction on what types are accepted. When it refers to output, it is not normally a restriction, therefore "constraint" is inappropriate. Instead it is normally described as a coercion, cast or conversion. Automatic type conversions are the opposite of a constraint: it is a loosening of restrictions. "I don't have to use a list, I can use any sequence or iterator". In iterator unpacking, it is the *output* which is a list, not a restriction on input: in the statement: head, *tail = sequence tail may not exist before the assignment, and so describing this as a constraint on the type of tail is completely inappropriate. > The statement: > > head, tail = sequence > > Signifies regular unpacking. However, if we add an asterisk, as in: > > head, *tail = sequence > > We demand that tail not be just any python object, but rather a list. We don't demand anything, any more than when we say: for x in range(1, 100): we "demand" that x is not just any python object, but rather an int. Rather, we accept what we're given: in case of range and the for loop, we are given an int. In the case of extended tuple unpacking, we are given a list. > This changes the semantics from normal unpacking, to unpacking and then > repacking all but the head into a list. Aside: iterator unpacking is more general than just head/tail unpacking. >>> a, b, *var, c, d, e = range(10) >>> print(a, b, c, d, e, var) 0 1 7 8 9 [2, 3, 4, 5, 6] You are jumping to conclusions about implementation details which aren't supported by the visible behaviour. What evidence do you have that iterator unpacking creates a tuple first and then converts it to a list? > It may be somewhat counter-intuitive to think of this as a type > constraint, since python is after all a weakly-typed language. The usual test of a weakly-typed language is that "1"+1 succeeds (and usually gives 2), as in Perl but not Python. I believe you are confusing weak typing with dynamic typing, a common mistake. [...] > The aim of this PEP, is that this type-constraint syntax is expanded > upon. We should be careful here to distinguish with providing optional > type constraints throughout python as a whole; this is not our aim. Iterator unpacking is no more about type constraints than is len(). -- Steven -- http://mail.python.org/mailman/listinfo/python-list
