Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #17408 > unrolled thread

Pythonification of the asterisk-based collection packing/unpacking syntax

Back to article view | Back to comp.lang.python

Contents

  Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-17 06:38 -0800
    Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-17 17:00 +0000
      Re: Pythonification of the asterisk-based collection packing/unpacking syntax Roy Smith <roy@panix.com> - 2011-12-17 12:14 -0500
        Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-18 04:18 +1100
          Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-17 12:11 -0800
            Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-17 23:20 +0000
    Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-18 00:59 +0000
      Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-18 13:45 +1100
        Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-18 03:33 +0000
          Re: Pythonification of the asterisk-based collection packing/unpacking syntax Roy Smith <roy@panix.com> - 2011-12-17 22:59 -0500
            Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-18 15:05 +1100
      Re: Pythonification of the asterisk-based collection packing/unpacking syntax Evan Driscoll <edriscoll@wisc.edu> - 2011-12-17 21:03 -0600
        Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-18 08:46 +0000
      Re: Pythonification of the asterisk-based collection packing/unpacking syntax Evan Driscoll <edriscoll@wisc.edu> - 2011-12-17 21:08 -0600
      Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-18 14:42 +1100
      Re: Pythonification of the asterisk-based collection packing/unpacking syntax Evan Driscoll <edriscoll@wisc.edu> - 2011-12-17 22:43 -0600
      Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-18 16:00 +1100
      Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-18 06:13 -0800
        Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-18 17:03 +0000
          Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-18 09:40 -0800
    Re: Pythonification of the asterisk-based collection packing/unpacking syntax buck <workitharder@gmail.com> - 2011-12-17 20:52 -0800
      Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-18 16:21 +1100
      Re: Pythonification of the asterisk-based collection packing/unpacking syntax Evan Driscoll <edriscoll@wisc.edu> - 2011-12-17 23:33 -0600
        Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-18 07:31 +0000
          Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-18 19:43 +1100
            Re: Pythonification of the asterisk-based collection packing/unpacking syntax Roy Smith <roy@panix.com> - 2011-12-18 08:58 -0500
              Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-19 01:06 +1100
          Re: Pythonification of the asterisk-based collection packing/unpacking syntax Evan Driscoll <edriscoll@wisc.edu> - 2011-12-18 13:56 -0600
            Re: Pythonification of the asterisk-based collection packing/unpacking syntax Duncan Booth <duncan.booth@invalid.invalid> - 2011-12-19 15:23 +0000
        Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-18 08:36 +0000
          Re: Pythonification of the asterisk-based collection packing/unpacking syntax Evan Driscoll <edriscoll@wisc.edu> - 2011-12-18 13:47 -0600
            Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-19 01:26 +0000
              Re: Pythonification of the asterisk-based collection packing/unpacking syntax Rick Johnson <rantingrickjohnson@gmail.com> - 2011-12-18 18:16 -0800
                Re: Pythonification of the asterisk-based collection packing/unpacking syntax Andrew Berg <bahamutzero8825@gmail.com> - 2011-12-19 15:57 -0600
                  Re: Pythonification of the asterisk-based collection packing/unpacking syntax Roy Smith <roy@panix.com> - 2011-12-19 19:30 -0500
                    Re: Pythonification of the asterisk-based collection packing/unpacking syntax Andrew Berg <bahamutzero8825@gmail.com> - 2011-12-19 19:41 -0600
                  Re: Pythonification of the asterisk-based collection packing/unpacking syntax alex23 <wuwei23@gmail.com> - 2011-12-19 19:38 -0800
                    Re: Pythonification of the asterisk-based collection packing/unpacking syntax Andrew Berg <bahamutzero8825@gmail.com> - 2011-12-19 22:04 -0600
                    Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-20 20:51 +0000
              Re: Pythonification of the asterisk-based collection packing/unpacking syntax Ian Kelly <ian.g.kelly@gmail.com> - 2011-12-18 20:00 -0700
                Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-19 03:36 +0000
        Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-18 06:35 -0800
          Re: Pythonification of the asterisk-based collection packing/unpacking syntax Evan Driscoll <edriscoll@wisc.edu> - 2011-12-18 14:20 -0600
            Re: Pythonification of the asterisk-based collection packing/unpacking syntax alex23 <wuwei23@gmail.com> - 2011-12-18 18:23 -0800
              Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-19 15:35 +1100
                Re: Pythonification of the asterisk-based collection packing/unpacking syntax alex23 <wuwei23@gmail.com> - 2011-12-19 19:31 -0800
                  Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-20 15:10 +1100
              Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-19 02:15 -0800
                Re: Pythonification of the asterisk-based collection packing/unpacking syntax alex23 <wuwei23@gmail.com> - 2011-12-19 19:30 -0800
                  Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-24 06:39 -0800
                    Re: Pythonification of the asterisk-based collection packing/unpacking syntax alex23 <wuwei23@gmail.com> - 2011-12-24 16:24 -0800
                      Re: Pythonification of the asterisk-based collection packing/unpacking syntax Rick Johnson <rantingrickjohnson@gmail.com> - 2011-12-24 17:01 -0800
                        Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-25 06:45 -0800
                    Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-25 13:12 +0000
                      Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-25 07:38 -0800
                        Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-26 03:23 +1100
                          Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-26 12:58 -0800
                            Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-27 08:05 +1100
                              Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-26 14:12 -0800
                                Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-27 09:37 +1100
                        Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-25 17:05 +0000
                          Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-26 13:41 -0800
                            Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-27 22:57 +0000
                              Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-28 03:57 -0800
          Re: Pythonification of the asterisk-based collection packing/unpacking syntax Rick Johnson <rantingrickjohnson@gmail.com> - 2011-12-18 17:04 -0800
        Re: Pythonification of the asterisk-based collection packing/unpacking syntax Rick Johnson <rantingrickjohnson@gmail.com> - 2011-12-18 16:59 -0800
          Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-19 02:20 -0800
            Re: Pythonification of the asterisk-based collection packing/unpacking syntax alex23 <wuwei23@gmail.com> - 2011-12-19 19:35 -0800
              Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-20 05:47 +0000
                Re: Pythonification of the asterisk-based collection packing/unpacking syntax alex23 <wuwei23@gmail.com> - 2011-12-19 22:39 -0800
                Re: Pythonification of the asterisk-based collection packing/unpacking syntax Serhiy Storchaka <storchaka@gmail.com> - 2011-12-20 11:58 +0200
                Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-24 06:45 -0800
                  Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-25 02:01 +1100
                    Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-24 09:23 -0800
                      Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-25 04:51 +1100
                  Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-25 12:50 +0000
                    Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-25 06:59 -0800
              Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-24 06:41 -0800
            Re: Pythonification of the asterisk-based collection packing/unpacking syntax Neal Becker <ndbecker2@gmail.com> - 2011-12-21 10:48 -0500
              Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-24 06:47 -0800
                Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-25 01:57 +1100
                  Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-24 09:21 -0800
                Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-25 13:13 +0000
                  Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-25 07:47 -0800
                    Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-27 23:10 +0000
                      Re: Pythonification of the asterisk-based collection packing/unpacking syntax Rick Johnson <rantingrickjohnson@gmail.com> - 2011-12-27 17:11 -0800
                        Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-28 04:05 -0800
                      Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-28 15:06 +1100
                        Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-28 06:25 +0000
                          Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-28 18:08 +1100
                            Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-28 04:08 -0800
                              Re: Pythonification of the asterisk-based collection packing/unpacking syntax Lie Ryan <lie.1296@gmail.com> - 2011-12-29 09:29 +1100
                                Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-29 03:55 -0800
                                  Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-29 13:23 +0000
                                    Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-29 06:20 -0800
                                    Re: Pythonification of the asterisk-based collection packing/unpacking syntax Lie Ryan <lie.1296@gmail.com> - 2011-12-30 10:24 +1100
                                    Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-30 10:30 +1100
            Re: Pythonification of the asterisk-based collection packing/unpacking syntax Ethan Furman <ethan@stoneleaf.us> - 2011-12-21 08:33 -0800
      Re: Pythonification of the asterisk-based collection packing/unpacking syntax Evan Driscoll <edriscoll@wisc.edu> - 2011-12-17 23:54 -0600
      Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-18 06:23 -0800
      Re: Pythonification of the asterisk-based collection packing/unpacking syntax Rick Johnson <rantingrickjohnson@gmail.com> - 2011-12-18 16:57 -0800
    Re: Pythonification of the asterisk-based collection packing/unpacking syntax Neal Becker <ndbecker2@gmail.com> - 2011-12-22 06:49 -0500
      Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-22 13:12 +0000
        Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-23 00:30 +1100
        Re: Pythonification of the asterisk-based collection packing/unpacking syntax Hans Mulder <hansmu@xs4all.nl> - 2011-12-22 15:13 +0100
          Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-23 01:30 +1100
            Re: Pythonification of the asterisk-based collection packing/unpacking syntax Mel Wilson <mwilson@the-wire.com> - 2011-12-22 10:06 -0500
        Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-24 06:54 -0800
          Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-25 12:45 +0000
            Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-25 06:55 -0800
              Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-25 16:15 +0000
                Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-26 12:39 -0800
                  Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-27 08:01 +1100
                    Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-26 13:51 -0800
                      Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-27 09:27 +1100
                        Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-26 15:44 -0800
                          Re: Pythonification of the asterisk-based collection packing/unpacking syntax Chris Angelico <rosuav@gmail.com> - 2011-12-27 11:52 +1100
                            Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-27 02:01 -0800
                              Re: Pythonification of the asterisk-based collection packing/unpacking syntax alex23 <wuwei23@gmail.com> - 2012-01-02 18:38 -0800
                                Re: Pythonification of the asterisk-based collection packing/unpacking syntax Rick Johnson <rantingrickjohnson@gmail.com> - 2012-01-02 21:39 -0800
                                  Re: Pythonification of the asterisk-based collection packing/unpacking syntax alex23 <wuwei23@gmail.com> - 2012-01-02 23:01 -0800
                                Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2012-01-03 03:21 -0800
                      Re: Pythonification of the asterisk-based collection packing/unpacking syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-27 23:07 +0000
                        Re: Pythonification of the asterisk-based collection packing/unpacking syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-28 04:04 -0800

Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7  Next page →

#17920

On Sun, 25 Dec 2011 07:38:17 -0800, Eelco wrote:

> On Dec 25, 2:12 pm, Steven D'Aprano <steve
> +comp.lang.pyt...@pearwood.info> wrote:
>> On Sat, 24 Dec 2011 06:39:39 -0800, Eelco wrote:
>> > On Dec 20, 4:30 am, alex23 <wuwe...@gmail.com> wrote:
>> >> On Dec 19, 8:15 pm, Eelco <hoogendoorn.ee...@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.
> 
> Did I waste any more words on collection packing and type constraints?
> No, I did not. (though I am about to, and am willing to do so for every
> question that seems genuinely aimed at engaging me on the matter)
> 
> Did I intend to say that I was going to let a single troll shut down my
> entire topic? No, I did not.

Ah, well whatever you *intended* wasn't clear from your comment. At least 
not clear to *me*.


[...]
> Yes, indeed it would be abuse of language to call this a type
> constraint, since the fact that y is a list is indeed an outcome of
> whatever happens to pop out at the right hand side. One could redefine
> the identifier list to return any kind of object.

So far, we agree on this.

> How is 'head, *tail = sequence' or semantically entirely equivalently,
> 'head, tail::list = sequence' any different then? Of course after
> interpretation/compilation, what it boils down to is that we are
> constructing a list and binding it to the identifier tail, but that is
> not how it is formulated in python as a language 

I'm afraid it is.

Here's the definition of assignment in Python 3:
http://docs.python.org/py3k/reference/simple_stmts.html#assignment-
statements


> (all talk of types is
> meaningless after compilation; machine code is untyped).

What does machine code have to do with Python?


> We dont have
> something of the form 'tail = list_tail(sequence)'.

I'm afraid we do. See the definition of assignment again.


> Rather, we annotate
> the identifier 'tail' with an attribute that unquestionably destinates
> it to become a list*. It is no longer that 'tail' will just take
> anything that pops out of the expression on the right hand side; 

Of course it will. Python is a dynamically typed language. It doesn't 
suddenly develop static types to ensure that 'tail' becomes a list; 
'tail' is bound to a list because that's what the assignment statement 
provides.


> rather,
> the semantics of what will go on at right hand side is coerced by the
> constraint placed on 'tail'.

But it isn't a constraint placed on 'tail'. It is a consequence of the 
definition of assignment in Python 3. 'tail' becomes bound to a list 
because that is what the assignment statement is defined to do in that 
circumstance, not because the identifier (symbol) 'tail' is constrained 
to only accept lists. 'tail' may not even exist before hand, so talking 
about constraints on 'tail' is an abuse of language, AS YOU AGREED ABOVE.


[...]
> *(I call that a 'type constraint', because that is what it literally is;


No. It is literally a name binding of a dynamically typed, unconstrained 
name to an object which happens to be a list.


> if you can make a case that this term has acquired a different meaning
> in practice, and that there is another term in common use for this kind
> of construct; please enlighten me. Until that time, im going to ask you
> to take 'type constraint' by its literal meaning; a coercion of the type
> of a symbol,

But THERE IS NO COERCION OF THE TYPE OF THE SYMBOL.

I am sorry for shouting, but you seem oblivious to the simple fact that 
Python is not statically typed, and the symbol 'tail' is NOT coerced to a 
specific type. 'tail' may not even exist before the assignment is made; 
if it does exist, it could be *any type at all* -- and after the 
assignment takes place, there are no restrictions on subsequent 
assignments. 

'head, *tail = sequence' is no more a type constraint than 'x = 1' is.

Whatever the virtues of your proposal, you are doing it incalculable harm 
by your insistence on this incorrect model of Python's behaviour. 


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#17982

On Dec 25, 6:05 pm, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> On Sun, 25 Dec 2011 07:38:17 -0800, Eelco wrote:
> > On Dec 25, 2:12 pm, Steven D'Aprano <steve
> > +comp.lang.pyt...@pearwood.info> wrote:
> >> On Sat, 24 Dec 2011 06:39:39 -0800, Eelco wrote:
> >> > On Dec 20, 4:30 am, alex23 <wuwe...@gmail.com> wrote:
> >> >> On Dec 19, 8:15 pm, Eelco <hoogendoorn.ee...@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.
>
> > Did I waste any more words on collection packing and type constraints?
> > No, I did not. (though I am about to, and am willing to do so for every
> > question that seems genuinely aimed at engaging me on the matter)
>
> > Did I intend to say that I was going to let a single troll shut down my
> > entire topic? No, I did not.
>
> Ah, well whatever you *intended* wasn't clear from your comment. At least
> not clear to *me*.

Always glad to help.

> > Yes, indeed it would be abuse of language to call this a type
> > constraint, since the fact that y is a list is indeed an outcome of
> > whatever happens to pop out at the right hand side. One could redefine
> > the identifier list to return any kind of object.
>
> So far, we agree on this.

Good.

> > How is 'head, *tail = sequence' or semantically entirely equivalently,
> > 'head, tail::list = sequence' any different then? Of course after
> > interpretation/compilation, what it boils down to is that we are
> > constructing a list and binding it to the identifier tail, but that is
> > not how it is formulated in python as a language
>
> I'm afraid it is.
>
> Here's the definition of assignment in Python 3:http://docs.python.org/py3k/reference/simple_stmts.html#assignment-
> statements

Que?

'head, *tail = sequence'

Is how one currently unpacks a head and tail in idiomatic python

This is semantically equivalent to

'head = sequence[0]'
'tail = list(sequence[1:])'

But these forms are linguistically different, in too many different
ways to mention.

> > We dont have
> > something of the form 'tail = list_tail(sequence)'.
>
> I'm afraid we do. See the definition of assignment again.

Que?

My claim is that the two semantically identical formulations above do
not have isomorphic linguistic form. As far as I can make sense of
your words, you seem to be disputing this claim, but its a claim as
much worth debating as that the sun rises in the east.

> > Rather, we annotate
> > the identifier 'tail' with an attribute that unquestionably destinates
> > it to become a list*. It is no longer that 'tail' will just take
> > anything that pops out of the expression on the right hand side;
>
> Of course it will. Python is a dynamically typed language. It doesn't
> suddenly develop static types to ensure that 'tail' becomes a list;
> 'tail' is bound to a list because that's what the assignment statement
> provides.

How python accomplishes any of this under the hood is entirely
immaterial. The form is that of a compile-time type constraint,
regardless of whether the BDFL ever thought about it in these terms.

> > rather,
> > the semantics of what will go on at right hand side is coerced by the
> > constraint placed on 'tail'.
>
> But it isn't a constraint placed on 'tail'. It is a consequence of the
> definition of assignment in Python 3. 'tail' becomes bound to a list
> because that is what the assignment statement is defined to do in that
> circumstance, not because the identifier (symbol) 'tail' is constrained
> to only accept lists. 'tail' may not even exist before hand, so talking
> about constraints on 'tail' is an abuse of language, AS YOU AGREED ABOVE.

'tail' is (re)declared on the spot as a brand-new identifier (type
constraint included); whether it exists before has no significance
whatsoever, since python allows rebinding of identifiers.

> > *(I call that a 'type constraint', because that is what it literally is;
>
> No. It is literally a name binding of a dynamically typed, unconstrained
> name to an object which happens to be a list.

Let me take a step back and reflect on the form of the argument we are
having. I claim the object in front of us is a 'cube'. You deny this
claim, by countering that it is 'just a particular configuration of
atoms'.

'look at the definition!', you say; 'its just a list of coordinates,
no mention of cubes whatsoever.'.

'Look at the definition of a cube', I counter. 'This particular list
of coordinates happens to fit the definition, whether the BDFT
intended to or not'.

You are correct, in the sense that I do not disagree that it is a
particular configuration of atoms. But if you had a better
understanding of cubes, youd realize it meets the definition; the fact
that people might not make a habit of pausing at this fact (there is
generally speaking not much of a point in doing so in this case), does
not diminish the validity of this perspective. But again, if this
perspective does not offer you anything useful, feel free not to share
in it.

> > if you can make a case that this term has acquired a different meaning
> > in practice, and that there is another term in common use for this kind
> > of construct; please enlighten me. Until that time, im going to ask you
> > to take 'type constraint' by its literal meaning; a coercion of the type
> > of a symbol,
>
> But THERE IS NO COERCION OF THE TYPE OF THE SYMBOL.
>
> I am sorry for shouting, but you seem oblivious to the simple fact that
> Python is not statically typed, and the symbol 'tail' is NOT coerced to a
> specific type. 'tail' may not even exist before the assignment is made;
> if it does exist, it could be *any type at all* -- and after the
> assignment takes place, there are no restrictions on subsequent
> assignments.
>
> 'head, *tail = sequence' is no more a type constraint than 'x = 1' is.
>
> Whatever the virtues of your proposal, you are doing it incalculable harm
> by your insistence on this incorrect model of Python's behaviour.

Whatever the virtues of your critique of my proposal, you might end up
wasting less time doing so by reading a book or two on compiler theory.

[toc] | [prev] | [next] | [standalone]

#18070

On Mon, 26 Dec 2011 13:41:34 -0800, Eelco wrote:

> On Dec 25, 6:05 pm, Steven D'Aprano <steve
> +comp.lang.pyt...@pearwood.info> wrote:
>> On Sun, 25 Dec 2011 07:38:17 -0800, Eelco wrote:
[...]

>> > How is 'head, *tail = sequence' or semantically entirely
>> > equivalently, 'head, tail::list = sequence' any different then? Of
>> > course after interpretation/compilation, what it boils down to is
>> > that we are constructing a list and binding it to the identifier
>> > tail, but that is not how it is formulated in python as a language
>>
>> I'm afraid it is.
>>
>> Here's the definition of assignment in Python 3:
>> http://docs.python.org/py3k/reference/simple_stmts.html#assignment-
>> statements
> 
> Que?

You have claimed that "constructing a list and binding it to the 
identifier" is not how iterator unpacking is formulated in Python the 
language. But that is wrong. That *is* how iterator unpacking is 
formulated in Python the language. The reference manual goes into detail 
on how assignment is defined in Python. You should read it.


> 'head, *tail = sequence'
> 
> Is how one currently unpacks a head and tail in idiomatic python
> 
> This is semantically equivalent to
> 
> 'head = sequence[0]'
> 'tail = list(sequence[1:])'

There's a reason this feature is called *iterable* unpacking: it operates 
on any iterable object, not just indexable sequences. 

'head, *tail = sequence' is not just semantically equivalent to, but 
*actually is* implemented as something very close to:

temp = iter(sequence)
head = next(temp)
tail = list(temp)
del temp

Extended iterable unpacking, as in 'head, *middle, tail = sequence' is a 
little more complex, but otherwise the same: it operates using the 
iterator protocol, not indexing. I recommend you read the PEP, if you 
haven't already done so.

http://www.python.org/dev/peps/pep-3132/


> But these forms are linguistically different, in too many different ways
> to mention.

How about mentioning even one way? Because I have no idea what 
differences you are referring to, or why you think they are important.


>> > We dont have
>> > something of the form 'tail = list_tail(sequence)'.
>>
>> I'm afraid we do. See the definition of assignment again.
> 
> Que?

Again, you make a claim about Python which is contradicted by the 
documented behaviour of the language. You claim that we DON'T have 
something of the form 'tail = list_tail(sequence)', but that is *exactly* 
what we DO have: extracting the tail from an iterator.

Obviously there is no built-in function "list_tail" but we get the same 
effect by just using list() on an iterator after advancing past the first 
item.


> My claim is that the two semantically identical formulations above do
> not have isomorphic linguistic form. As far as I can make sense of your
> words, you seem to be disputing this claim, but its a claim as much
> worth debating as that the sun rises in the east.

"Isomorphic linguistic form"? Are you referring to the idea from 
linguistics that there are analogies between the structure of phonic and 
semantic units? E.g. that the structures (phoneme, syllable, word) and 
(sememe, onomateme, sentence) are analogous.

I don't see why this is relevant, or which units you are referring to -- 
the human-language description of what Python does, high-level Python 
language features, Python byte-code, or machine code. Not that it 
matters, but it is unlikely that any of those are isomorphic in the 
linguistic sense, and I am not making any general claim that they are.

If not, I have no idea what you are getting at, except possibly trying to 
hide behind obfuscation.



>> > Rather, we annotate
>> > the identifier 'tail' with an attribute that unquestionably
>> > destinates it to become a list*. It is no longer that 'tail' will
>> > just take anything that pops out of the expression on the right hand
>> > side;
>>
>> Of course it will. Python is a dynamically typed language. It doesn't
>> suddenly develop static types to ensure that 'tail' becomes a list;
>> 'tail' is bound to a list because that's what the assignment statement
>> provides.
> 
> How python accomplishes any of this under the hood is entirely
> immaterial. The form is that of a compile-time type constraint,
> regardless of whether the BDFL ever thought about it in these terms.

Compile-time type constraints only have meaning in statically-typed 
languages. Otherwise, you are applying an analogy that simply doesn't 
fit, like claiming that the motion of paper airplanes and birds are 
equivalent just because in English we use the word "fly" to describe them 
both.

The differences between what Python actually does and compile-time type-
constraints are greater than the similarities.

Similarities:

(1) In both cases, 'tail' ends up as a list.

Differences:

(1) Compiler enforces the constraint that the identifier 'tail' is always 
associated with a list and will prevent any attempt to associate 'tail' 
with some value that is not a list. Python does nothing like this: the 
identifier 'tail' has no type restrictions at all, and can be used for 
any object.

(2) Errors are detectable at compile-time with an error that halts 
compilation; Python detects errors at runtime with an exception that can 
be caught and by-passed without halting execution.

(3) "Constraint" has the conventional meaning of a restriction, not a 
result; a type-constraint refers to a variable being prevented from being 
set to some other type, not that it merely becomes set to that type. For 
example, one doesn't refer to 'x = 1' as a type-constraint merely because 
x gets set to an int value; why do you insist that 'head, *tail = 
sequence' is a type-constraint merely because tail gets set to a list?



>> > rather,
>> > the semantics of what will go on at right hand side is coerced by the
>> > constraint placed on 'tail'.
>>
>> But it isn't a constraint placed on 'tail'. It is a consequence of the
>> definition of assignment in Python 3. 'tail' becomes bound to a list
>> because that is what the assignment statement is defined to do in that
>> circumstance, not because the identifier (symbol) 'tail' is constrained
>> to only accept lists. 'tail' may not even exist before hand, so talking
>> about constraints on 'tail' is an abuse of language, AS YOU AGREED
>> ABOVE.
> 
> 'tail' is (re)declared on the spot as a brand-new identifier (type
> constraint included); whether it exists before has no significance
> whatsoever, since python allows rebinding of identifiers.

Given the following:

tail = "beautiful red plumage"
head, *tail = [1, 2, 3, 4]
tail = 42

is it your option that all three instantiations of the *identifier* 
'tail' (one in each line) are *different* identifiers? Otherwise, your 
statement about "brand new identifier" is simply wrong.

If you allow that they are the same identifier with three different 
values (and three different types), then this completely destroys your 
argument that there is a constraint on the identifier 'tail'. First 
'tail' is a string, then it is a list, then it is an int. If that is a 
type constraint (restriction) on 'tail', then constraint has no meaning.

If you state that they are three different identifiers that just happen 
to be identical in every way that can be detected, then you are engaged 
in counting angels dancing on the head of pins. Given this idea that the 
middle 'tail' identifier is a different identifier from the other two, 
then I might accept that there *could* be a type-constraint on middle 
'tail', at least in some implementation of Python that hasn't yet been 
created. But what a pointless argument to make.


>> > *(I call that a 'type constraint', because that is what it literally
>> > is;
>>
>> No. It is literally a name binding of a dynamically typed,
>> unconstrained name to an object which happens to be a list.
> 
> Let me take a step back and reflect on the form of the argument we are
> having. I claim the object in front of us is a 'cube'. You deny this
> claim, by countering that it is 'just a particular configuration of
> atoms'.

No no no, you have utterly misunderstood my argument. I'm not calling it 
a configuration of atoms. I'm calling it a pyramid, and pointing out that 
no matter how many times you state it is a cube, it actually has FOUR 
sides, not six, and NONE of the sides are square, so it can't possibly be 
a cube.



> 'look at the definition!', you say; 'its just a list of coordinates, no
> mention of cubes whatsoever.'.
> 
> 'Look at the definition of a cube', I counter. 'This particular list of
> coordinates happens to fit the definition, whether the BDFT intended to
> or not'.

But you are wrong. It does not fit the definition of a type-constraint, 
except in the vacuous sense where you declare that there is some 
invisible distinction between the identifier 'tail' in one statement and 
the identical identifier 'tail' in another statement.


> You are correct, in the sense that I do not disagree that it is a
> particular configuration of atoms. But if you had a better understanding
> of cubes, youd realize it meets the definition;

I might not share your deep and expert understanding of cubes, but I 
understand what "type-constraint" means, and I know what Python does in 
iterator unpacking, and I know that there is no sensible definition of 
type-constraint that applies to iterator unpacking in Python.


> the fact that people
> might not make a habit of pausing at this fact (there is generally
> speaking not much of a point in doing so in this case), does not
> diminish the validity of this perspective. But again, if this
> perspective does not offer you anything useful, feel free not to share
> in it.

Quite frankly, I should just let you witter on about type-constraints, 
because (again, in my opinion) it destroys your credibility and will 
reduce even further the already minuscule chance that your proposal will 
be accepted. Since I'm against the idea, I should encourage you to 
describe Python's behaviour in terms that will all but guarantee others 
will dismiss you as knowing little or nothing about Python.

[...]
> Whatever the virtues of your critique of my proposal, you might end up
> wasting less time doing so by reading a book or two on compiler theory.

Perhaps you should spend more time considering the reality of how Python 
works and less time trying to force the triangular peg of Python concepts 
into the square hole of your ideas about theoretical compilers.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#18113

On Dec 27, 11:57 pm, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> On Mon, 26 Dec 2011 13:41:34 -0800, Eelco wrote:
> > On Dec 25, 6:05 pm, Steven D'Aprano <steve
> > +comp.lang.pyt...@pearwood.info> wrote:
> >> On Sun, 25 Dec 2011 07:38:17 -0800, Eelco wrote:
>
> [...]
>
> >> > How is 'head, *tail = sequence' or semantically entirely
> >> > equivalently, 'head, tail::list = sequence' any different then? Of
> >> > course after interpretation/compilation, what it boils down to is
> >> > that we are constructing a list and binding it to the identifier
> >> > tail, but that is not how it is formulated in python as a language
>
> >> I'm afraid it is.
>
> >> Here's the definition of assignment in Python 3:
> >>http://docs.python.org/py3k/reference/simple_stmts.html#assignment-
> >> statements
>
> > Que?
>
> You have claimed that "constructing a list and binding it to the
> identifier" is not how iterator unpacking is formulated in Python the
> language. But that is wrong. That *is* how iterator unpacking is
> formulated in Python the language. The reference manual goes into detail
> on how assignment is defined in Python. You should read it.
>
> > 'head, *tail = sequence'
>
> > Is how one currently unpacks a head and tail in idiomatic python
>
> > This is semantically equivalent to
>
> > 'head = sequence[0]'
> > 'tail = list(sequence[1:])'
>
> There's a reason this feature is called *iterable* unpacking: it operates
> on any iterable object, not just indexable sequences.
>
> 'head, *tail = sequence' is not just semantically equivalent to, but
> *actually is* implemented as something very close to:
>
> temp = iter(sequence)
> head = next(temp)
> tail = list(temp)
> del temp
>
> Extended iterable unpacking, as in 'head, *middle, tail = sequence' is a
> little more complex, but otherwise the same: it operates using the
> iterator protocol, not indexing. I recommend you read the PEP, if you
> haven't already done so.
>
> http://www.python.org/dev/peps/pep-3132/
>
> > But these forms are linguistically different, in too many different ways
> > to mention.
>
> How about mentioning even one way? Because I have no idea what
> differences you are referring to, or why you think they are important.

The one spans two lines; the other one. Need I go on?

> >> > We dont have
> >> > something of the form 'tail = list_tail(sequence)'.
>
> >> I'm afraid we do. See the definition of assignment again.
>
> > Que?
>
> Again, you make a claim about Python which is contradicted by the
> documented behaviour of the language. You claim that we DON'T have
> something of the form 'tail = list_tail(sequence)', but that is *exactly*
> what we DO have: extracting the tail from an iterator.
>
> Obviously there is no built-in function "list_tail" but we get the same
> effect by just using list() on an iterator after advancing past the first
> item.
>
> > My claim is that the two semantically identical formulations above do
> > not have isomorphic linguistic form. As far as I can make sense of your
> > words, you seem to be disputing this claim, but its a claim as much
> > worth debating as that the sun rises in the east.
>
> "Isomorphic linguistic form"? Are you referring to the idea from
> linguistics that there are analogies between the structure of phonic and
> semantic units? E.g. that the structures (phoneme, syllable, word) and
> (sememe, onomateme, sentence) are analogous.
>
> I don't see why this is relevant, or which units you are referring to --
> the human-language description of what Python does, high-level Python
> language features, Python byte-code, or machine code. Not that it
> matters, but it is unlikely that any of those are isomorphic in the
> linguistic sense, and I am not making any general claim that they are.
>
> If not, I have no idea what you are getting at, except possibly trying to
> hide behind obfuscation.

I wasnt too worried about obfuscation, since I think there is little
left to lose on that front. Let me make a last-ditch effort to explain
though:

When python reads your code, it parses it into a symbolic graph
representation. The two snippets under consideration do not parse into
the same graph, in the same way that insignificant whitespace or
arbitrary identifier names do, for instance. Hence, not linguistically
isomorphic.

The very function of a programming language is to transform this
representation of the code into semantically identical but different
code; (machine code, eventually). You fail to grok the difference
between semantic equivalence and linguistic equivalence. Yes, there
can be a semantic equivalence between iterable unpacking and a syntax
of the form tail_list(sequence). And python does indeed probably apply
a transformation of this kind under the hood (though we couldnt care
less what it does exactly). AND IT PERFORMS THAT TRANSFORMATION USING
THE TYPE CONSTRAINT GIVEN.

Another example: the C code 'float x = 3', how would you interpret
that? Is it 'not a type constraint on x', because eventually your C
compiler turns it into machine code that doesnt leave a trace of that
type constraint anyway? No, its a type constraint, exactly because C
uses it to emit code specific to the type specified.

> >> > Rather, we annotate
> >> > the identifier 'tail' with an attribute that unquestionably
> >> > destinates it to become a list*. It is no longer that 'tail' will
> >> > just take anything that pops out of the expression on the right hand
> >> > side;
>
> >> Of course it will. Python is a dynamically typed language. It doesn't
> >> suddenly develop static types to ensure that 'tail' becomes a list;
> >> 'tail' is bound to a list because that's what the assignment statement
> >> provides.
>
> > How python accomplishes any of this under the hood is entirely
> > immaterial. The form is that of a compile-time type constraint,
> > regardless of whether the BDFL ever thought about it in these terms.
>
> Compile-time type constraints only have meaning in statically-typed
> languages. Otherwise, you are applying an analogy that simply doesn't
> fit, like claiming that the motion of paper airplanes and birds are
> equivalent just because in English we use the word "fly" to describe them
> both.
>
> The differences between what Python actually does and compile-time type-
> constraints are greater than the similarities.
>
> Similarities:
>
> (1) In both cases, 'tail' ends up as a list.
>
> Differences:
>
> (1) Compiler enforces the constraint that the identifier 'tail' is always
> associated with a list and will prevent any attempt to associate 'tail'
> with some value that is not a list. Python does nothing like this: the
> identifier 'tail' has no type restrictions at all, and can be used for
> any object.

After it is rebound, yes. Within the context of the iterable unpacking
statement however, IT IS ALWAYS A LIST. Not only is it always a list,
PYTHON *NEEDS* THIS KNOWLEDGE ABOUT TAIL TO EMIT THE CORRECT CODE
(explicitly or implicitly; thats why I say 'it can be viewed as a type
constraint')

Just because the type constraint only applies within the statement
does not make it any less of a type constraint; just one with
different semantics, from say, C.

> (3) "Constraint" has the conventional meaning of a restriction, not a
> result; a type-constraint refers to a variable being prevented from being
> set to some other type, not that it merely becomes set to that type. For
> example, one doesn't refer to 'x = 1' as a type-constraint merely because
> x gets set to an int value; why do you insist that 'head, *tail =
> sequence' is a type-constraint merely because tail gets set to a list?

Yes, the constraint is unique in this case; that does not make it any
less of a constraint. A formula of the form 'x = 1' is called a
constraint in mathematics. Collections with one element are still
called collections. Do you have a problem with that too?

> >> > rather,
> >> > the semantics of what will go on at right hand side is coerced by the
> >> > constraint placed on 'tail'.
>
> >> But it isn't a constraint placed on 'tail'. It is a consequence of the
> >> definition of assignment in Python 3. 'tail' becomes bound to a list
> >> because that is what the assignment statement is defined to do in that
> >> circumstance, not because the identifier (symbol) 'tail' is constrained
> >> to only accept lists. 'tail' may not even exist before hand, so talking
> >> about constraints on 'tail' is an abuse of language, AS YOU AGREED
> >> ABOVE.
>
> > 'tail' is (re)declared on the spot as a brand-new identifier (type
> > constraint included); whether it exists before has no significance
> > whatsoever, since python allows rebinding of identifiers.
>
> Given the following:
>
> tail = "beautiful red plumage"
> head, *tail = [1, 2, 3, 4]
> tail = 42
>
> is it your option that all three instantiations of the *identifier*
> 'tail' (one in each line) are *different* identifiers? Otherwise, your
> statement about "brand new identifier" is simply wrong.
>
> If you allow that they are the same identifier with three different
> values (and three different types), then this completely destroys your
> argument that there is a constraint on the identifier 'tail'. First
> 'tail' is a string, then it is a list, then it is an int. If that is a
> type constraint (restriction) on 'tail', then constraint has no meaning.
>
> If you state that they are three different identifiers that just happen
> to be identical in every way that can be detected, then you are engaged
> in counting angels dancing on the head of pins. Given this idea that the
> middle 'tail' identifier is a different identifier from the other two,
> then I might accept that there *could* be a type-constraint on middle
> 'tail', at least in some implementation of Python that hasn't yet been
> created. But what a pointless argument to make.
>
> >> > *(I call that a 'type constraint', because that is what it literally
> >> > is;
>
> >> No. It is literally a name binding of a dynamically typed,
> >> unconstrained name to an object which happens to be a list.
>
> > Let me take a step back and reflect on the form of the argument we are
> > having. I claim the object in front of us is a 'cube'. You deny this
> > claim, by countering that it is 'just a particular configuration of
> > atoms'.
>
> No no no, you have utterly misunderstood my argument. I'm not calling it
> a configuration of atoms. I'm calling it a pyramid, and pointing out that
> no matter how many times you state it is a cube, it actually has FOUR
> sides, not six, and NONE of the sides are square, so it can't possibly be
> a cube.

For that to be true, you would have had to explain to me somewhere
what it is you mean by a type constraint, and how this does not fit
the bill. Granted, you did that for the first time in this post; and I
added further detail why I think your particular usage of the term is
too narrow; C does not have a unique claim to the concept. Or
whereever you picked up your use of the term. Like I said, I mean it
in its literal sense (and in the sense that happens to match the first
hit on google; probably no coincidence).

> > 'look at the definition!', you say; 'its just a list of coordinates, no
> > mention of cubes whatsoever.'.
>
> > 'Look at the definition of a cube', I counter. 'This particular list of
> > coordinates happens to fit the definition, whether the BDFT intended to
> > or not'.
>
> But you are wrong. It does not fit the definition of a type-constraint,
> except in the vacuous sense where you declare that there is some
> invisible distinction between the identifier 'tail' in one statement and
> the identical identifier 'tail' in another statement.

Its not vacuous; its essential to the mechanics behind the
transformation of the iterable unpacking statement to its compiled
form. But its meaning does not carry beyond that, no.

> > You are correct, in the sense that I do not disagree that it is a
> > particular configuration of atoms. But if you had a better understanding
> > of cubes, youd realize it meets the definition;
>
> I might not share your deep and expert understanding of cubes, but I
> understand what "type-constraint" means, and I know what Python does in
> iterator unpacking, and I know that there is no sensible definition of
> type-constraint that applies to iterator unpacking in Python.

You seem to know what a type constraint is in a language like C, and
you seem to model your complete understanding from that particular
instance of its use, rather than look at the actual definition of the
term, and seeing where it might apply.

[toc] | [prev] | [next] | [standalone]

#17486

On Dec 18, 8:35 am, Eelco <hoogendoorn.ee...@gmail.com> wrote:
> On Dec 18, 6:33 am, Evan Driscoll <edrisc...@wisc.edu> wrote:

> Good point; technically the askeriskes could be kept for backwards
> compatibility, but that would break 'there should only be one way to
> do it'.

I believe it's high time for the upper society of this community to
realize that the small breaks in backward compatibility in Python 3000
were only the beginning. Python is evolving past even what Guido could
have dreamed. He can not hold the reins of this unwieldy beast any
longer.

[toc] | [prev] | [next] | [standalone]

#17485

On Dec 17, 11:33 pm, Evan Driscoll <edrisc...@wisc.edu> wrote:
> On 12/17/2011 22:52, buck wrote:> Try these on for size.
>
> >      head, @tuple tail = sequence
> >      def foo(@list args, @dict kwargs): pass
> >      foo(@args, @kwargs)
>
> > For backward compatibility, we could say that the unary * is identical to @list and unary ** is identical to @dict.
>
> I like this idea much more than the original one.

+1. I will second that! Eelco has the CORRECT idea, but the WRONG
syntax!

[toc] | [prev] | [next] | [standalone]

#17507

On Dec 19, 1:59 am, Rick Johnson <rantingrickjohn...@gmail.com> wrote:
> On Dec 17, 11:33 pm, Evan Driscoll <edrisc...@wisc.edu> wrote:
>
> > On 12/17/2011 22:52, buck wrote:> Try these on for size.
>
> > >      head, @tuple tail = sequence
> > >      def foo(@list args, @dict kwargs): pass
> > >      foo(@args, @kwargs)
>
> > > For backward compatibility, we could say that the unary * is identical to @list and unary ** is identical to @dict.
>
> > I like this idea much more than the original one.
>
> +1. I will second that! Eelco has the CORRECT idea, but the WRONG
> syntax!

Thanks, your opinion is noted.

Personally im impartial between identifier::collectiontype and
identifier@collectiontype, but that order is something I think is
rather important.

Having two seperate symbols seperated by whitespace, as in @list args
strikes me as a terrible break of normal python lexical rules. Plus,
identifier@collectiontype as a collection-type annotation would be
consistent with the existing general function annotation syntax. Many
non-C-family languages postfix the type declaration.

Also, we want to use the same symbol for collection unpacking as we
use for collection packing. Saying foo(@argslist) really does look a
tad much like a decorator, even though it can be unambigiously
distinguished from it by context.

[toc] | [prev] | [next] | [standalone]

#17543

Eelco <hoogendoorn.ee...@gmail.com> wrote:
> Having two seperate symbols seperated by whitespace, as in @list args
> strikes me as a terrible break of normal python lexical rules.

You mean like 'is not'? And the upcoming 'yield from'?

[toc] | [prev] | [next] | [standalone]

#17558

On Mon, 19 Dec 2011 19:35:20 -0800, alex23 wrote:

> Eelco <hoogendoorn.ee...@gmail.com> wrote:
>> Having two seperate symbols seperated by whitespace, as in @list args
>> strikes me as a terrible break of normal python lexical rules.
> 
> You mean like 'is not'? And the upcoming 'yield from'?

Also "not in".

Space-delimited tokens are hardly rare in Python, e.g.:

import module as name
for x in sequence
if flag 
elif condition
while condition
with obj
del name


Nevertheless, I think the suggested syntax "@list args" is awful.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#17562

Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote:
> Nevertheless, I think the suggested syntax "@list args" is awful.

Yep, and it's the least awful part of the entire proposal.

[toc] | [prev] | [next] | [standalone]

#17568

20.12.11 07:47, Steven D'Aprano написав(ла):
> Space-delimited tokens are hardly rare in Python, e.g.:
>
> import module as name
> for x in sequence
> if flag
> elif condition
> while condition
> with obj
> del name

return to_be or not to_be if this is question else None

[toc] | [prev] | [next] | [standalone]

#17846

On Dec 20, 6:47 am, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> On Mon, 19 Dec 2011 19:35:20 -0800, alex23 wrote:
> > Eelco <hoogendoorn.ee...@gmail.com> wrote:
> >> Having two seperate symbols seperated by whitespace, as in @list args
> >> strikes me as a terrible break of normal python lexical rules.
>
> > You mean like 'is not'? And the upcoming 'yield from'?
>
> Also "not in".
>
> Space-delimited tokens are hardly rare in Python, e.g.:
>
> import module as name
> for x in sequence
> if flag
> elif condition
> while condition
> with obj
> del name
>
> Nevertheless, I think the suggested syntax "@list args" is awful.
>
> --
> Steven

Can you give an example of a construct in python where two whitespace
delimited identifiers are legal?

[toc] | [prev] | [next] | [standalone]

#17849

On Sun, Dec 25, 2011 at 1:45 AM, Eelco <hoogendoorn.eelco@gmail.com> wrote:
> Can you give an example of a construct in python where two whitespace
> delimited identifiers are legal?

What do you mean? Two identifiers, separated only by whitespace and no
keyword or operator?

def foo():
    asdf
    qwer

Perfectly legal, two statements that probably don't do anything useful though.

ChrisA

[toc] | [prev] | [next] | [standalone]

#17857

On Dec 24, 4:01 pm, Chris Angelico <ros...@gmail.com> wrote:
> On Sun, Dec 25, 2011 at 1:45 AM, Eelco <hoogendoorn.ee...@gmail.com> wrote:
> > Can you give an example of a construct in python where two whitespace
> > delimited identifiers are legal?
>
> What do you mean? Two identifiers, separated only by whitespace and no
> keyword or operator?
>
> def foo():
>     asdf
>     qwer
>
> Perfectly legal, two statements that probably don't do anything useful though.
>
> ChrisA

Thats not a fair point, but more nitpicking. Yes, I should have been
more precise: in python, 'whitespace' is not a single beast like in
most languages, but newlines have a special meaning. I was obviously
not talking about those. Want to try again?

[toc] | [prev] | [next] | [standalone]

#17861

On Sun, Dec 25, 2011 at 4:23 AM, Eelco <hoogendoorn.eelco@gmail.com> wrote:
> Thats not a fair point, but more nitpicking. Yes, I should have been
> more precise: in python, 'whitespace' is not a single beast like in
> most languages, but newlines have a special meaning. I was obviously
> not talking about those. Want to try again?

In that case I can't think of any, but at least now you've clarified
the question (by not denying the rest of it). It was somewhat
ambiguous.

ChrisA

[toc] | [prev] | [next] | [standalone]

#17885

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

> Can you give an example of a construct in python where two whitespace
> delimited identifiers are legal?

Not apart from the trivial case of two identifiers separated by newlines.

What's your point?


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#17913

On Dec 25, 1:50 pm, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> On Sat, 24 Dec 2011 06:45:01 -0800, Eelco wrote:
> > Can you give an example of a construct in python where two whitespace
> > delimited identifiers are legal?
>
> Not apart from the trivial case of two identifiers separated by newlines.
>
> What's your point?

My point is as I originally stated it: that this construct, of two
identifiers seperated by non-newline whitespace, as in 'list tail'
does not occur anywhere else in python, so introducing that syntax,
while i suppose technically possible, would be a break with existing
expectations. Normally speaking, if two identifiers interact, they are
explicitly 'joined' by an infixed operator of some sort, as in 3*4,
rather than * 3 4. That seems a sensible rule to me, and I see no
compelling reason to depart from it.

[toc] | [prev] | [next] | [standalone]

#17845

On Dec 20, 4:35 am, alex23 <wuwe...@gmail.com> wrote:
> Eelco <hoogendoorn.ee...@gmail.com> wrote:
> > Having two seperate symbols seperated by whitespace, as in @list args
> > strikes me as a terrible break of normal python lexical rules.
>
> You mean like 'is not'? And the upcoming 'yield from'?

Im not sure why, but this feels like something entirely different to
me.

I suppose because these are compositions of keywords. Can you give an
example of a whitespaced composition of identifiers being a valid
construct anywhere else in Python?

[toc] | [prev] | [next] | [standalone]

#17670

Clarification: where can packing/unpacking syntax be used?

It would be great if it were valid essentially anywhere (not limited to 
parameter passing).

What about constructs like:

a, @tuple tail, b = sequence?

[toc] | [prev] | [next] | [standalone]

#17844

On Dec 21, 4:48 pm, Neal Becker <ndbeck...@gmail.com> wrote:
> Clarification: where can packing/unpacking syntax be used?
>
> It would be great if it were valid essentially anywhere (not limited to
> parameter passing).
>
> What about constructs like:
>
> a, @tuple tail, b = sequence?

This has come up many times in the thread, including in my OP. More
closely unifying collection packing/unpacking is part of my goal, so
indeed, I would like to be able to write something like:

a, middle::tuple, b = ::sequence

Where I would like the extra :: before the sequence to explicitly
signal collection unpacking on the rhs, to maintain the symmetry with
collection unpacking within a function call.

[toc] | [prev] | [next] | [standalone]

Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7  Next page →

Back to top | Article view | comp.lang.python

csiph-web