On Dec 25, 2:12 pm, Steven D'Aprano <steve +comp.lang.pyt...@pearwood.info> wrote: > On Sat, 24 Dec 2011 06:39:39 -0800, Eelco wrote: > > On Dec 20, 4:30 am, alex23 <wuwe...@gmail.com> wrote: > >> On Dec 19, 8:15 pm, Eelco <hoogendoorn.ee...@gmail.com> wrote: > > >> > What does that have to do with collection packing/unpacking? > > >> It's mocking your insistance that collection unpacking is a type > >> constraint. > > > This is really going to be the last time I waste any words on this: > > If only that were true, but after sending this post, you immediately > followed up with FIVE more posts on this subject in less than half an > hour.
Did I waste any more words on collection packing and type constraints? No, I did not. (though I am about to, and am willing to do so for every question that seems genuinely aimed at engaging me on the matter) Did I intend to say that I was going to let a single troll shut down my entire topic? No, I did not. > > In case of python, collection PACKING (not unpacking) is signaled by a > > construct that can be viewed as a type constraint. > > Only by doing sufficient violence to the concept of type constraint that > it could mean *anything*. > > Earlier, I insisted that a constraint is a rule that applies to input, > not output. I haven't seen anyone, including yourself, dispute that. > > Normally we would say that in the statement: > > y = list(x) > > there is a constraint on x, namely that it is some sort of iterable > object (otherwise an exception will be raised), but it would be an abuse > of language to say that there is a type constraint on y. y ends up being > a list, true, but that isn't a constraint on y, it is an outcome. > > In normal usage, "constraint" refers to pre-conditions, not post- > conditions. There are no pre-conditions on y in the above. It may not > even exist. Contrast it with this example: > > y += list(x) > > where there are constraints on y: it must exist, and it must be a list, > or something which can be added to a list. Yes, indeed it would be abuse of language to call this a type constraint, since the fact that y is a list is indeed an outcome of whatever happens to pop out at the right hand side. One could redefine the identifier list to return any kind of object. How is 'head, *tail = sequence' or semantically entirely equivalently, 'head, tail::list = sequence' any different then? Of course after interpretation/compilation, what it boils down to is that we are constructing a list and binding it to the identifier tail, but that is not how it is formulated in python as a language (all talk of types is meaningless after compilation; machine code is untyped). We dont have something of the form 'tail = list_tail(sequence)'. Rather, we annotate the identifier 'tail' with an attribute that unquestionably destinates it to become a list*. It is no longer that 'tail' will just take anything that pops out of the expression on the right hand side; rather, the semantics of what will go on at right hand side is coerced by the constraint placed on 'tail'. But again, if you dont wish to view this as a type constraint, I wont lose any sleep over that. In that case this line of argument was simply never directed at you. It was directed at people who would reasonably argue that 'tail::tuple is a type constraint and thats unpythonic / type constraints have been considered and rejected'. If you dont think it looks like a type constraint: fine. The simpler argument is that whatever it is, its just a more verbose and flexible variant of a construct that python already has. *(I call that a 'type constraint', because that is what it literally is; if you can make a case that this term has acquired a different meaning in practice, and that there is another term in common use for this kind of construct; please enlighten me. Until that time, im going to ask you to take 'type constraint' by its literal meaning; a coercion of the type of a symbol, rather than whatever particular meaning it has acquired for you (it might help if you explained that). Im not sure if it was you that brought that up, but let me reiterate that I dont mean a 'type cast', which is a runtime concept. A 'type constraint' is purely a linguistic construct that will be 'compiled out') -- http://mail.python.org/mailman/listinfo/python-list
