Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!tudelft.nl!txtfeed1.tudelft.nl!multikabel.net!newsfeed20.multikabel.net!news2.euro.net!newsfeed.xs4all.nl!newsfeed6.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <82fd3bec-5afa-4e87-ae9a-8f93ecb9e366@dp8g2000vbb.googlegroups.com>
References: <841f4d29-f50b-4b0b-912b-b497fb6e60ec@t16g2000vba.googlegroups.com> <mailman.3785.1324186443.27778.python-list@python.org> <298b28e6-b8c9-43e1-8c90-cf0d7654fe68@y12g2000vba.googlegroups.com> <mailman.3806.1324239668.27778.python-list@python.org> <56f0073e-e259-4a9d-bd3a-1221fd74c5b1@d8g2000vbb.googlegroups.com> <a755fac7-422f-4348-8aef-3ac0f26cd5f9@z25g2000vbs.googlegroups.com> <7191d569-5036-4800-b7a3-fcacb000de94@d10g2000vbk.googlegroups.com> <930f748a-db7c-4ecc-9627-a3ab2647ae65@o14g2000vbo.googlegroups.com> <4ef72149$0$29973$c3e8da3$5496439d@news.astraweb.com> <457ebc8f-bb87-4005-b527-2fe6c02250c8@m7g2000vbc.googlegroups.com> <mailman.4078.1324830189.27778.python-list@python.org> <14c228af-0de5-448f-b617-832173aa6cba@p4g2000vbt.googlegroups.com> <mailman.4110.1324933521.27778.python-list@python.org> <82fd3bec-5afa-4e87-ae9a-8f93ecb9e366@dp8g2000vbb.googlegroups.com>
Date: Tue, 27 Dec 2011 09:37:06 +1100
Subject: Re: Pythonification of the asterisk-based collection packing/unpacking syntax
From: Chris Angelico <rosuav@gmail.com>
To: python-list@python.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.4113.1324939029.27778.python-list@python.org>
Lines: 57
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:17987

On Tue, Dec 27, 2011 at 9:12 AM, Eelco <hoogendoorn.eelco@gmail.com> wrote:
> On Dec 26, 10:05=A0pm, Chris Angelico <ros...@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