Pythonification of the asterisk-based collection packing/unpacking syntax

[Chris Angelico]

On Tue, Dec 27, 2011 at 9:12 AM, Eelco <hoogendoorn.eelco at gmail.com> wrote:
> On Dec 26, 10:05 pm, Chris Angelico <ros... at gmail.com> wrote:
>> 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.

A constraint failure causes an error at the time it's discovered.
1) Your editor pops up a message the instant you type something with
such an error, and forces you to correct it before going on.
2) Your compiler refuses to produce byte-code for the module.
3) When the line of code is executed, an exception is thrown.
All of these are valid ways of handling a constraint. Here is a Python
example of a type constraint:

def foo(arg):
    if not isinstance(arg,list): raise "This won't work."

If you call it with something that's not a list, you get an error.
Call it with a list, and execution continues normally. That's a
constraint. Of course, it might not be a _type_ constraint:

def foo(arg):
   if arg>5: raise "This won't work either." # and yes, that's oddly
truer in Python 3

(Aside: In Pike, I can actually put that into a type constraint
(declare the argument to be int(5..) for instance). This, however, is
not germane to the conversation.)

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

Like Mary Poppins, I never apologize for derailing threads :)

>> 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).

Of course, but how can Python, without a completely different
structure, do compile-time checking of object types? Everything can be
monkey-patched at run-time. Anything could be affected by any function
call. It's impossible to say for certain, at compile time, what data
type anything will have.

ChrisA