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 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7  Next page →

#17848

On Sun, Dec 25, 2011 at 1:47 AM, Eelco <hoogendoorn.eelco@gmail.com> wrote:
> a, middle::tuple, b = ::sequence

Then it ought to be

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

or something, because you're doing the same thing on both sides.

ChrisA

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

#17855

On Dec 24, 3:57 pm, Chris Angelico <ros...@gmail.com> wrote:
> On Sun, Dec 25, 2011 at 1:47 AM, Eelco <hoogendoorn.ee...@gmail.com> wrote:
> > a, middle::tuple, b = ::sequence
>
> Then it ought to be
>
> ::(a, middle::tuple, b) = ::sequence
>
> or something, because you're doing the same thing on both sides.
>
> ChrisA

Thats a fair point; something to think about. It all depends on how
you define the rules of course; im trying to stay as close as possible
to the original python rules, where the (un)packing of comma-seperated
identifiers is implicit. Probably best to keep it that way, from the
looks of it :).

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

#17888

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

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

The :: on the right-hand side is redundant, because the left-hand side 
already explicitly signals collection unpacking of the RHS. Requiring :: 
on the RHS above is as unnecessary as it would be here:

    n = len(::sequence)



-- 
Steven

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

#17916

On Dec 25, 2:13 pm, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> On Sat, 24 Dec 2011 06:47:21 -0800, Eelco wrote:
> > 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.
>
> The :: on the right-hand side is redundant, because the left-hand side
> already explicitly signals collection unpacking of the RHS. Requiring ::
> on the RHS above is as unnecessary as it would be here:

Yes, it is redundant; hence the word 'extra' in my post.

Explicit and implicit are not well-defined terms, but I would say that
at the moment the signal is implicit, in the sense that one cannot see
what is going on by considering the rhs in isolation. Normally in
python, an assignment just binds the rhs to the identifiers on the
lhs, but in case of collection (un)packing, this rule that holds
almost all of the time is broken, and the assignment statement implies
a far more complicated construct, with a far more subtle meaning, and
non-constant time complexity.

Thats not a terrible thing, but a little extra explicitness there
would not hurt, and like I argued many times before, it is a nice
unification with the situation where the unpacking can not be
implicit, like inside a function call rather than assignment.


>     n = len(::sequence)

Now you are just discrediting yourself in terms of having any idea
what you are talking about.

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

#18076

On Sun, 25 Dec 2011 07:47:20 -0800, Eelco wrote:

> Explicit and implicit are not well-defined terms, 

We can at least agree on that.

> but I would say that
> at the moment the signal is implicit, in the sense that one cannot see
> what is going on by considering the rhs in isolation. 

That is a ridiculous argument. If you ignore half the statement, of 
course you can't tell what is going on.


> Normally in
> python, an assignment just binds the rhs to the identifiers on the lhs,
> but in case of collection (un)packing, this rule that holds almost all
> of the time is broken, and the assignment statement implies a far more
> complicated construct, with a far more subtle meaning, and non-constant
> time complexity.

Python assignment in general is not constant time.

If the left hand side is a single identifier (a name, a dotted attribute, 
a subscription or slice, etc.) then the assignment is arguably constant 
time (hand-waving away complications like attribute access, hash table 
collisions, descriptors, etc.); but if the left hand side is a list of 
targets, e.g.:

a, b, c = sequence

then the assignment is O(N). Python has to walk the sequence (actually, 
any iterator) and assign each of N items to N identifiers, hence O(N) not 
O(1).

The trivial case of a single value on the left hand side:

x = 1

is just the degenerate case for N=1.


> Thats not a terrible thing, but a little extra explicitness there would
> not hurt, 

I think it will. It makes the assignment more verbose to no benefit.


> and like I argued many times before, it is a nice unification
> with the situation where the unpacking can not be implicit, like inside
> a function call rather than assignment.

That's one opinion; but there's no need for any "extra explicitness" 
since the definition of assignment in Python already explicitly includes 
iterable unpacking. How much explicitness do you need?



>>     n = len(::sequence)
> 
> Now you are just discrediting yourself in terms of having any idea what
> you are talking about.

::sequence is redundant and unnecessary whether it is inside a function 
call to len or on the right hand side of an assignment. In both cases, it 
adds nothing to the code except noise.

Your proposal is surreal. You started off this conversation arguing that 
the existing idiom for extended iterator unpacking, e.g.

head, *tail = sequence

is too hard to understand because it uses punctuation, and have ended up 
recommending that we replace it with:

head, tail:: = ::sequence 

instead (in the generic case where you don't want to use a different type 
for tail).

Your original use-case, where you want to change the type of tail from a 
list to something else, is simply solved by one extra line of code:

head, *tail = sequence
tail = tuple(tail)


You have written thousands of words to save one line in an idiom which 
you claim is very uncommon. Perhaps your understanding of "pythonic" is 
not as good as you imagine.



-- 
Steven

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

#18083

On Dec 27, 5:10 pm, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> On Sun, 25 Dec 2011 07:47:20 -0800, Eelco wrote:
> Your original use-case, where you want to change the type of tail from a
> list to something else, is simply solved by one extra line of code:
>
> head, *tail = sequence
> tail = tuple(tail)

i wonder if we could make this proposal a bit more "Pythonic"? Hmm...

head, tuple(tail) = sequence

...YEP!

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

#18115

On Dec 28, 2:11 am, Rick Johnson <rantingrickjohn...@gmail.com> wrote:
> On Dec 27, 5:10 pm, Steven D'Aprano <steve
>
> +comp.lang.pyt...@pearwood.info> wrote:
> > On Sun, 25 Dec 2011 07:47:20 -0800, Eelco wrote:
> > Your original use-case, where you want to change the type of tail from a
> > list to something else, is simply solved by one extra line of code:
>
> > head, *tail = sequence
> > tail = tuple(tail)
>
> i wonder if we could make this proposal a bit more "Pythonic"? Hmm...
>
> head, tuple(tail) = sequence
>
> ...YEP!

That has been considered; it was my first thought too, but this
requires one to break the symmetry between collection packing and
unpacking.

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

#18094

On Wed, Dec 28, 2011 at 10:10 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Your original use-case, where you want to change the type of tail from a
> list to something else, is simply solved by one extra line of code:
>
> head, *tail = sequence
> tail = tuple(tail)

That achieves the goal of having tail as a different type, but it does
have the additional cost of constructing and then discarding a
temporary list. I know this is contrived, but suppose you have a huge
set/frozenset using tuples as the keys, and one of your operations is
to shorten all keys by removing their first elements. Current Python
roughly doubles the cost of this operation, since you can't choose
what type the tail is made into.

But if that's what you're trying to do, it's probably best to slice
instead of unpacking. Fortunately, the Zen of Python "one obvious way
to do it" doesn't stop there being other ways that work too.

ChrisA

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

#18102

On Wed, 28 Dec 2011 15:06:37 +1100, Chris Angelico wrote:

> On Wed, Dec 28, 2011 at 10:10 AM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> Your original use-case, where you want to change the type of tail from
>> a list to something else, is simply solved by one extra line of code:
>>
>> head, *tail = sequence
>> tail = tuple(tail)
> 
> That achieves the goal of having tail as a different type, but it does
> have the additional cost of constructing and then discarding a temporary
> list. I know this is contrived, but suppose you have a huge
> set/frozenset using tuples as the keys, and one of your operations is to
> shorten all keys by removing their first elements. Current Python
> roughly doubles the cost of this operation, since you can't choose what
> type the tail is made into.

The First Rule of Program Optimization:
- Don't do it.

The Second Rule of Program Optimization (for experts only):
- Don't do it yet.


Building syntax to optimize imagined problems is rarely a good idea. The 
difference between 2 seconds processing your huge set and 4 seconds 
processing it is unlikely to be significant unless you have dozens of 
such huge sets and less than a minute to process them all.

And your idea of "huge" is probably not that big... it makes me laugh 
when people ask how to optimize code "because my actual data has HUNDREDS 
of items!". Whoop-de-doo. Come back when you have a hundred million 
items, then I'll take your question seriously.

(All references to "you" and "your" are generic, and not aimed at Chris 
personally. Stupid English language.)


> But if that's what you're trying to do, it's probably best to slice
> instead of unpacking.

Assuming the iterable is a sequence.

Fortunately, most iterable constructors accept iterators directly, so for 
the cost of an extra line (three instead of two), you can handle data 
structures as big as will fit into memory:

# I want to keep both the old and the new set
it = iter(huge_set_of_tuples)
head = next(it)  # actually an arbitrary item
tail = set(x[1:] for x in it)  # and everything else

If you don't need both the old and the new:

head = huge_set_of_tuples.pop()
tail = set()
while huge_set_of_tuples:
    tail.add(huge_set_of_tuples.pop()[1:])
assert huge_set_of_tuples == set([])

If you rely on language features, who knows how efficient the compiler 
will be?

head, tail::tuple = ::sequence

may create a temporary list before building the tuple anyway. And why 
not? That's what this *must* do:

head, second, middle::tuple, second_from_last, last = ::iterator

because tuples are immutable and can't be grown or shrunk, so why assume 
the language designers special cased the first form above?


> Fortunately, the Zen of Python "one obvious way to
> do it" doesn't stop there being other ways that work too.

Exactly. It is astonishing how many people think that if there isn't a 
built-in language feature, with special syntax, to do something, there's 
a problem that needs to be solved.


-- 
Steven

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

#18106

On Wed, Dec 28, 2011 at 5:25 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Wed, 28 Dec 2011 15:06:37 +1100, Chris Angelico wrote:
>
>> ... suppose you have a huge
>> set/frozenset using tuples as the keys, and one of your operations is to
>> shorten all keys by removing their first elements. Current Python
>> roughly doubles the cost of this operation, since you can't choose what
>> type the tail is made into.
>
> The First Rule of Program Optimization:
> - Don't do it.
>
> The Second Rule of Program Optimization (for experts only):
> - Don't do it yet.
>
>
> Building syntax to optimize imagined problems is rarely a good idea. The
> difference between 2 seconds processing your huge set and 4 seconds
> processing it is unlikely to be significant unless you have dozens of
> such huge sets and less than a minute to process them all.
>
> And your idea of "huge" is probably not that big... it makes me laugh
> when people ask how to optimize code "because my actual data has HUNDREDS
> of items!". Whoop-de-doo. Come back when you have a hundred million
> items, then I'll take your question seriously.
>
> (All references to "you" and "your" are generic, and not aimed at Chris
> personally. Stupid English language.)

And what you're seeing there is the _best possible_ situation I could
think of, the strongest possible justification for new syntax.
Granted, that may say more about me and my imagination than about the
problem, but the challenge is open: Come up with something that
actually needs this.

ChrisA

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

#18116

On Dec 28, 8:08 am, Chris Angelico <ros...@gmail.com> wrote:
> On Wed, Dec 28, 2011 at 5:25 PM, Steven D'Aprano
>
>
>
>
>
>
>
>
>
> <steve+comp.lang.pyt...@pearwood.info> wrote:
> > On Wed, 28 Dec 2011 15:06:37 +1100, Chris Angelico wrote:
>
> >> ... suppose you have a huge
> >> set/frozenset using tuples as the keys, and one of your operations is to
> >> shorten all keys by removing their first elements. Current Python
> >> roughly doubles the cost of this operation, since you can't choose what
> >> type the tail is made into.
>
> > The First Rule of Program Optimization:
> > - Don't do it.
>
> > The Second Rule of Program Optimization (for experts only):
> > - Don't do it yet.
>
> > Building syntax to optimize imagined problems is rarely a good idea. The
> > difference between 2 seconds processing your huge set and 4 seconds
> > processing it is unlikely to be significant unless you have dozens of
> > such huge sets and less than a minute to process them all.
>
> > And your idea of "huge" is probably not that big... it makes me laugh
> > when people ask how to optimize code "because my actual data has HUNDREDS
> > of items!". Whoop-de-doo. Come back when you have a hundred million
> > items, then I'll take your question seriously.
>
> > (All references to "you" and "your" are generic, and not aimed at Chris
> > personally. Stupid English language.)
>
> And what you're seeing there is the _best possible_ situation I could
> think of, the strongest possible justification for new syntax.
> Granted, that may say more about me and my imagination than about the
> problem, but the challenge is open: Come up with something that
> actually needs this.
>
> ChrisA

I personally feel any performance benefits are but a plus; they are
not the motivating factor for this idea. I simply like the added
verbosity and explicitness, thats the bottom line.

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

#18148

On 12/28/2011 11:08 PM, Eelco wrote:
> I personally feel any performance benefits are but a plus; they are
> not the motivating factor for this idea. I simply like the added
> verbosity and explicitness, thats the bottom line.

Any performance benefits are a plus, I agree, as long as it doesn't make 
my language looks like Perl. Now get off my lawn!

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

#18166

On Dec 28, 11:29 pm, Lie Ryan <lie.1...@gmail.com> wrote:
> On 12/28/2011 11:08 PM, Eelco wrote:
>
> > I personally feel any performance benefits are but a plus; they are
> > not the motivating factor for this idea. I simply like the added
> > verbosity and explicitness, thats the bottom line.
>
> Any performance benefits are a plus, I agree, as long as it doesn't make
> my language looks like Perl. Now get off my lawn!

Im no perl expert, but it says on the wikipedia page a common
criticism is its overuse of otherwise meaningless special characters;
and I would agree; I puked a little in my mouth looking at the code
samples.

I would argue that the use of single special characters to signal a
relatively complex and uncommon construct is exactly what I am trying
to avoid with this proposal.

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

#18171

On Thu, 29 Dec 2011 03:55:14 -0800, Eelco wrote:

> I would argue that the use of single special characters to signal a
> relatively complex and uncommon construct is exactly what I am trying to
> avoid with this proposal.

This would be the proposal to change the existing

    head, *tail = sequence

to your proposed:

    head, tail:: = ::sequence

(when happy with the default list for tail), or

    head, tail::tuple = ::sequence

to avoid an explicit call to "tail = tuple(tail)" after the unpacking.

Either way, with or without an explicit type declaration on the left hand 
side, you are increasing the number of punctuation characters from one to 
four. If your aim is to minimize the number of punctuation characters, 
you're doing it wrong.


-- 
Steven

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

#18174

On Dec 29, 2:23 pm, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> On Thu, 29 Dec 2011 03:55:14 -0800, Eelco wrote:
> > I would argue that the use of single special characters to signal a
> > relatively complex and uncommon construct is exactly what I am trying to
> > avoid with this proposal.
>
> This would be the proposal to change the existing
>
>     head, *tail = sequence
>
> to your proposed:
>
>     head, tail:: = ::sequence
>
> (when happy with the default list for tail), or
>
>     head, tail::tuple = ::sequence
>
> to avoid an explicit call to "tail = tuple(tail)" after the unpacking.
>
> Either way, with or without an explicit type declaration on the left hand
> side, you are increasing the number of punctuation characters from one to
> four. If your aim is to minimize the number of punctuation characters,
> you're doing it wrong.
>
> --
> Steven

The goal is not to minimize the number of (special) characters to
type. To goal is to minimize the number of special characters which
are hard to interpret at a glance. I would prefer : over ::, but both
are a single special character construct. Adding those characters once
more on the rhs is similarly, not an increase in the number of
concepts employed; merely a more explicit form of the same construct.

And besides, I dont much like 'head, tail:: = ::sequence'. I threw
that out there to appease the terseness advocates, but to me it
largely defeats the purpose, because indeed it is hardly any different
from the original. I like the explicit mentioning of the collection
type to be constructed; that is what really brings it more towards
'for line in file' explicit obviousness to my mind.

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

#18195

On 12/30/2011 12:23 AM, Steven D'Aprano wrote:
> On Thu, 29 Dec 2011 03:55:14 -0800, Eelco wrote:
>
>> I would argue that the use of single special characters to signal a
>> relatively complex and uncommon construct is exactly what I am trying to
>> avoid with this proposal.
>
> This would be the proposal to change the existing
>
>      head, *tail = sequence
>
> to your proposed:
>
>      head, tail:: = ::sequence
>
> (when happy with the default list for tail), or
>
>      head, tail::tuple = ::sequence
>
> to avoid an explicit call to "tail = tuple(tail)" after the unpacking.
>
> Either way, with or without an explicit type declaration on the left hand
> side, you are increasing the number of punctuation characters from one to
> four. If your aim is to minimize the number of punctuation characters,
> you're doing it wrong.

Another drawback of it is that it looks misleadingly similar to C++ 
namespace notation.

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

#18196

On Fri, Dec 30, 2011 at 10:24 AM, Lie Ryan <lie.1296@gmail.com> wrote:
> Another drawback of it is that it looks misleadingly similar to C++
> namespace notation.

Granted, but I don't see that as a drawback. The current notation is
just as similar to C's pointer-dereference notation, but that hasn't
led people to think that tail holds a pointer to the location where
something should be stored.

This would be a serious concern with notations that are common across
many languages (eg "x*y" to mean multiplication, which isn't strictly
what mathematics uses), but with language-specific notations,
especially such brief ones, it's understood that there'll be
duplication.

ChrisA

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

#17675

Neal Becker 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?

You mean like Python 3's:

a, *middle, b = sequence

?

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

#17438

[Multipart message — attachments visible in raw view] — view raw

On 12/17/2011 23:33, Evan Driscoll wrote:
> I do have one more thing to point out, which is that currently the
> Python vararg syntax is very difficult to Google for. In the first pages
> of the four searches matching "python (function)? (star | asterisk)",
> there was just one relevant hit on python.org which wasn't a bug report.
Though in the interest of full disclosure, and I should have said this
before, the first hit for all of those searches except "python star"
*is* relevant and reasonably helpful; just from someone's blog post
instead of "from the horse's mouth", so to speak.

Evan

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

#17459

On Dec 18, 5:52 am, buck <workithar...@gmail.com> wrote:
> I like the spirit of this. Let's look at your examples.

Glad to see an actual on-topic reply; thanks.

> > Examples of use:
> >     head, tail::tuple = ::sequence
> >     def foo(args::list, kwargs::dict): pass
> >     foo(::args, ::kwargs)
>
> My initial reaction was "nonono!", but this is simply because of the ugliness. The double-colon is very visually busy.

I would have preferred the single colon, but its taken. But exactly
this syntax is used in other languages (for what that is worth...)

> I find that your second example is inconsistent with the others. If we say that the variable-name is always on the right-hand-side, we get:
>
> >     def foo(list::args, dict::kwargs): pass
>
> This nicely mirrors other languages (such as in your C# example:  "float foo") as well as the old python behavior (prefixing variables with */** to modify the assignment).

The link in my OP has the BDFL discussing type constraints; he also
prefers identifier:type. Many modern languages have something similar.
How is my second example inconsistent?

> As for the separator, let's examine the available ascii punctuation. Excluding valid variable characters, whitespace, and operators, we have:
>
> ! -- ok.
> " -- can't use this. Would look like a string.
> # -- no. Would looks like a comment.
> $ -- ok.
> ' -- no. Would look like a string.
> ( -- no. Would look like a function.
> ) -- no. Would look like ... bad syntax.
> , -- no. Would indicate a separate item in the variable list.
> . -- no. Would look like an attribute.
> : -- ok, maybe. Seems confusing in a colon-terminated statement.
> ; -- no, just no.
> ? -- ok.
> @ -- ok.
> [ -- no. Would look like indexing.
> ] -- no.
> ` -- no. Would look like a string?
> { -- too strange} -- too strange
>
> ~ -- ok.
>
> That leaves these. Which one looks least strange?
>
> float ! x = 1
> float $ x = 1
> float ? x = 1
> float @ x = 1
>
> The last one looks decorator-ish, but maybe that's proper. The implementation of this would be quite decorator-like: take the "normal" value of x, pass it through the indicated function, assign that value back to x.

I dont think thats too proper an analogy. The type constraint does not
just coerce the content that is bound to the variable, it influences
the semantics of the whole statement; so insofar there is a suggested
relation with decorators, id rather not have it.


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

Yes, maximum backwards compatibility would be great.

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

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

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

csiph-web