Pythonification of the asterisk-based collection packing/unpacking syntax

[Eelco]

On Dec 25, 5:23 pm, Chris Angelico <ros... at gmail.com> wrote:
> On Mon, Dec 26, 2011 at 2:38 AM, Eelco <hoogendoorn.ee... at gmail.com> wrote:
> > 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')
>
> The dictionary definition of constraint is "a limitation or
> restriction", and you're right that it can be "compiled out". In fact,
> that is probably the best definition. Assuming everything is written
> correctly, you should be able to eliminate all constraints and the
> code will still function correctly*; but having the constrains means
> that certain illegal operations will throw errors.
>
> Here's two examples of tuple unpacking, one with a type constraint,
> the other without:
>
> a, b = ('hello', [1,2,3] )
> a, b::list = ('hello', [1,2,3] )
>
> The constraint on the second line means that, if the second element is
> not a list, the interpreter should throw an error. It does NOT mean to
> completely change the meaning of the statement to _make_ the last
> argument into a list. That is not the job of a constraint.

Thank you for providing clarification on what a 'type constraint'
means to you. That clears things up a bit.

What you are talking about goes by the name of a 'dynamic type CHECK';
some kind of syntactic sugar for something like
'assert(type(obj)==sometype)'. Like a 'type cast', this is also a
runtime concept. How you manage to confuse that with what I am talking
about, given that ive stated many times I am not talking about a
runtime construct but a compile-time construct, is quite beyond me.
(not to mention that ive quite explicitly stated what I mean by 'type
constraint' many times now).

By contrast, here is the first google hit for 'type constraint'.

http://msdn.microsoft.com/en-us/library/d5x73970.aspx

Note that this is a different application of the concept of a type
constraint, but nonetheless,  the concept is as I stated it: a
constraint to the type of a symbol to modify its compile-time
semantics. To cite from its first paragraph:

"...you can apply restrictions to the kinds of types ... by using a
type that is not allowed by a constraint, the result is a COMPILE-TIME
ERROR" (emphasis mine)