Pythonification of the asterisk-based collection packing/unpacking syntax

Steven D'Aprano steve+comp.lang.python at pearwood.info
Sun Dec 25 08:12:41 EST 2011


On Sat, 24 Dec 2011 06:39:39 -0800, Eelco wrote:

> On Dec 20, 4:30 am, alex23 <wuwe... at gmail.com> wrote:
>> On Dec 19, 8:15 pm, Eelco <hoogendoorn.ee... at 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.


> The sentence 'collection unpacking is a type constraint' is entirely
> nonsensical. 

How true. Given that you have now acknowledged this fact, can you please 
stop insisting that collection unpacking is a type constraint?


> A type constraint is a linguistical construct that can be
> applied in many ways; typically, to narrow down the semantics of use of
> the symbol to which the type constraint is applied.

Traceback (most recent call last):
RuntimeError: maximum recursion depth exceeded


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


-- 
Steven



More information about the Python-list mailing list