Pythonification of the asterisk-based collection packing/unpacking syntax

Eelco hoogendoorn.eelco at gmail.com
Mon Dec 26 17:12:23 EST 2011


On Dec 26, 10:05 pm, Chris Angelico <ros... at gmail.com> wrote:
> On Tue, Dec 27, 2011 at 7:58 AM, Eelco <hoogendoorn.ee... at gmail.com> wrote:
> > 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...
>
> > By contrast, here is the first google hit for 'type constraint'.
>
> >http://msdn.microsoft.com/en-us/library/d5x73970.aspx
>
> > "...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)
>
> A constraint can be applied at compile time or at run time. It'd be
> valid to apply them at edit time, if you so chose - your editor could
> refuse to save your file until you fix the problem. Doesn't mean a
> thing.

A constraint in the sense that I have explained many times now, can in
no way, shape or form be applied at run time. Youd have better luck
applying a consternation to a squirrel. Perhaps you meant 'type check'
again? But then again, that makes no sense whatsoever at compile-
time... Im starting to doubt if there is any sense to be found here at
all.

Anyway, ill take your further silence on the matter as a 'sorry I
derailed your thread with my confusion of terminology'

> Python, by its nature, cannot do compile-time type checking.

Python can do whatever its designers have put into it. In this case,
that includes the emission of different code based on a (type)
annotation at the point of declaration of an identifier (only in the
particular circumstance of collection unpacking though, as far as I am
aware).

> Under no circumstances, however, does this justify the use of the term
> "constraint" to mean "utterly different semantics of the same code".

Thank you for your theory on justice. Im sure its fascinating, but
until you get around to actually explaining it, im going to have to be
conservative and stick with the jargon in common use though, sorry.



More information about the Python-list mailing list