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

#17408 — Pythonification of the asterisk-based collection packing/unpacking syntax

This is a follow-up discussion on my earlier PEP-suggestion. Ive
integrated the insights collected during the previous discussion, and
tried to regroup my arguments for a second round of feedback. Thanks
to everybody who gave useful feedback the last time.

PEP Proposal: Pythonification of the asterisk-based collection packing/
unpacking syntax.

This proposal intends to expand upon the currently existing collection
packing and unpacking syntax. Thereby we mean the following related
python constructs:
    head, *tail = somesequence
    #pack the remainder of the unpacking of somesequence into a list
called tail
    def foo(*args): pass
    #pack the unbound positional arguments into a tuple calls args
    def foo(**kwargs): pass
    #pack the unbound keyword arguments into a dict calls kwargs
    foo(*args)
    #unpack the sequence args into positional arguments
    foo(**kwargs)
    #unpack the mapping kwargs into keyword arguments

We suggest that these constructs have the following shortcomings that
could be remedied.
It is unnecessarily cryptic, and out of line with Pythons preference
for an explicit syntax. One can not state in a single line what the
asterisk operator does; this is highly context dependent, and is
devoid of that ‘for line in file’ pythonic obviousness. From the
perspective of a Python outsider, the only hint as to what *args means
is by loose analogy with the C-way of handling variable arguments.
The current syntax, in its terseness, leaves to be desired in terms of
flexibility. While a tuple might be the logical choice to pack
positional arguments in the vast majority of cases, it need not be
true that a list is always the preferred choice to repack an unpacked
sequence, for instance.


Type constraints:

In case the asterisk is not used to signal unpacking, but rather to
signal packing, its semantics is essentially that of a type
constraint. The statement:

    head, tail = sequence

Signifies regular unpacking. However, if we add an asterisk, as in:

    head, *tail = sequence

We demand that tail not be just any python object, but rather a list.
This changes the semantics from normal unpacking, to unpacking and
then repacking all but the head into a list.

It may be somewhat counter-intuitive to think of this as a type
constraint, since python is after all a weakly-typed language. But the
current usage of askeriskes is an exception to that rule. For those
who are unconvinced, please consider the analogy to the following
simple C# code:

    var foo = 3;

An ‘untyped‘ object foo is created (actually, its type will be
inferred from its rhs as an integer).

    float foo = 3;

By giving foo a type-constraint of float instead, the semantics are
modified; foo is no longer the integer 3, but gets silently cast to
3.0. This is a simple example, but conceptually entirely analogous to
what happens when one places an asterisk before an lvalue in Python.
It means ‘be a list, and adjust your behavior accordingly’, versus ‘be
a float, and adjust your behavior accordingly’.

The aim of this PEP, is that this type-constraint syntax is expanded
upon. We should be careful here to distinguish with providing optional
type constraints throughout python as a whole; this is not our aim.
This concept has been considered before, but the costs have not been
found to out-weight the benefits. http://www.artima.com/weblogs/viewpost.jsp?thread=86641
Our primary aim is the niche of collection packing/unpacking, but if
further generalizations can be made without increasing the cost, those
are most welcome. To reiterate: what is proposed is nothing radical;
merely to replace the asterisk-based type constraints with a more
explicit type constraint.

Currently favored alternative syntax:

Both for the sake of explicitness and flexibility, we consider it
desirable that the name of the collection type is used directly in any
collection packing statement. Annotating a variable declaration with a
collection type name should signal collection packing. This
association between a collection type name and a variable declaration
can be accomplished in many ways; for now, we suggest
collectionname::collectiontype for packing, and ::collectionname for
unpacking.

Examples of use:
    head, tail::tuple = ::sequence
    def foo(args::list, kwargs::dict): pass
    foo(::args, ::kwargs)

The central idea is to replace annotations with asteriskes by
annotations with collection type names, but note that we have opted
for several other minor alterations of the existing syntax that seem
natural given the proposed changes.

First of all, explicitly mentioning the type of the collection
involved eliminates the need to have two symbols, * and **. Which
variable captures the positional arguments and which captures the
keyword arguments can be inferred from the collection type they model,
mapping or sequence. The rare case of collections that both model a
sequence and a mapping can either be excluded or handled by assigning
precedence for one type or the other.

A double semicolon before a collection type signals unpacking. As with
declarations, there is no genuine need to have a different operator
for sequence and mapping types, although if such a demand exists, it
would not be hard to accommodate. A double semicolon in front of the
collection is congruent with the asterisk syntax, and nicely
emphasizes this unpacking operation being the symmetric counterpart of
the packing operation, which is signalled by the same symbols to the
right of the identifier. Since we are going to make the double
semicolon (or whatever the symbol) a general collection packing/
unpacking marker, we feel it makes sense to allow it to be used to
explicitly signify unpacking, even when as much is implied by the
syntax on the left hand side, to preserve symmetry with the syntax
inside function calls.

Summarizing, what this syntax achieves, in loose order of perceived
importance:
Simplicity: we have reduced a set of rather arbitrary rules concerning
the syntax and semantics of the asterisk (does it construct a list or
a tuple?) to a single general symbol: the double semicolon is the
collection packing/unpacking annotation symbol, and that is all there
is to know about it.
Readability: the proposed syntax reads like a book: args-list and
kwargs-dict, unlike the more cryptic asterisk syntax. We avoid extra
lines of code in the event another sequence or mapping type than the
one returned by default is required.
Efficiency: by declaring the desired collection type, it can be
constructed in the optimal way from the given input, rather than
requiring a conversion after the default collection type is
constructed.

A double semicolon is suggested, since the single colon is already
taken by the function annotation syntax in Python 3. This is somewhat
unfortunate: programming should come before meta-programming, and it
should rather be the other way around. On the one hand having both :
and :: as variable declaration annotation symbols is a nice
unification, on the other hand, a syntax more easily visually
distinguished from function annotations can be defended. For increased
backwards compatibility the asterisk could be used, but sandwiched
between two identifiers it looks like a multiplication. But many
others symbols would do, such as @ or !.

[toc] | [next] | [standalone]

#17411

On Sat, 17 Dec 2011 06:38:22 -0800, Eelco wrote:

> One can not state in a single line what the asterisk
> operator does; 

Multiplication, exponentiation, sequence packing/unpacking, and varargs.


-- 
Steven

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

#17413

In article <4eeccabe$0$29979$c3e8da3$5496439d@news.astraweb.com>,
 Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:

> On Sat, 17 Dec 2011 06:38:22 -0800, Eelco wrote:
> 
> > One can not state in a single line what the asterisk
> > operator does; 
> 
> Multiplication, exponentiation, sequence packing/unpacking, and varargs.

Import wildcarding?

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

#17414

On Sun, Dec 18, 2011 at 4:14 AM, Roy Smith <roy@panix.com> wrote:
> Import wildcarding?

That's not an operator, any more than it is when used in filename
globbing. The asterisk _character_ has many meanings beyond those of
the operators * and **.

ChrisA

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

#17417

On Dec 17, 6:18 pm, Chris Angelico <ros...@gmail.com> wrote:
> On Sun, Dec 18, 2011 at 4:14 AM, Roy Smith <r...@panix.com> wrote:
> > Import wildcarding?
>
> That's not an operator, any more than it is when used in filename
> globbing. The asterisk _character_ has many meanings beyond those of
> the operators * and **.
>
> ChrisA

To cut short this line of discussion; I meant the asterisk symbol
purely in the context of collection packing/unpacking. Of course it
has other uses too.

Even that single use requires a whole paragraph to explain completely;
when does it result in a tuple or a list, when is unpacking implicit
and when not, why * versus **, and so on.

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

#17419

On Sat, 17 Dec 2011 12:11:04 -0800, Eelco wrote:

> > One can not state in a single line what the asterisk
> > operator does; 
...
> To cut short this line of discussion; I meant the asterisk symbol purely
> in the context of collection packing/unpacking. Of course it has other
> uses too.
> 
> Even that single use requires a whole paragraph to explain completely;
> when does it result in a tuple or a list, when is unpacking implicit and
> when not, why * versus **, and so on.

Do you think that this paragraph will become shorter if you change the 
spelling * to something else?

It takes more than one line to explain list comprehensions, content 
managers, iterators, range(), and import. Why should we care if * and ** 
also take more than one paragraph? Even if you could get it down to a 
single line, what makes you think that such extreme brevity is a good 
thing?

You might not be able to explain them in a single line, but you can 
explain them pretty succinctly:

    Varags: Inside a function parameter list, * collects an arbitrary
    number of positional arguments into a tuple. When calling functions,
    * expands any iterator into positional arguments. In both cases, **
    does the same thing for keyword arguments.

    Extended iterator unpacking: On the left hand side of an assignment,
    * collects multiple values from the right hand side into a list.


Let's see you do better with your suggested syntax. How concisely can you 
explain the three functions?

Don't forget the new type coercions (not constraints, as you keep calling 
them) you're introducing. It boggles my mind that you complain about the 
complexity of existing functionality, and your solution involves 
*increasing* the complexity with more functionality.



-- 
Steven

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

#17421

On Sat, 17 Dec 2011 06:38:22 -0800, Eelco wrote:

> Type constraints:
> 
> In case the asterisk is not used to signal unpacking, but rather to
> signal packing, its semantics is essentially that of a type constraint.

"Type constraint" normally refers to type restrictions on *input*: it is 
a restriction on what types are accepted. When it refers to output, it is 
not normally a restriction, therefore "constraint" is inappropriate. 
Instead it is normally described as a coercion, cast or conversion. 
Automatic type conversions are the opposite of a constraint: it is a 
loosening of restrictions. "I don't have to use a list, I can use any 
sequence or iterator".


In iterator unpacking, it is the *output* which is a list, not a 
restriction on input: in the statement:

head, *tail = sequence

tail may not exist before the assignment, and so describing this as a 
constraint on the type of tail is completely inappropriate.



> The statement:
> 
>     head, tail = sequence
> 
> Signifies regular unpacking. However, if we add an asterisk, as in:
> 
>     head, *tail = sequence
> 
> We demand that tail not be just any python object, but rather a list.

We don't demand anything, any more than when we say:

for x in range(1, 100):

we "demand" that x is not just any python object, but rather an int.

Rather, we accept what we're given: in case of range and the for loop, we 
are given an int. In the case of extended tuple unpacking, we are given a 
list.



> This changes the semantics from normal unpacking, to unpacking and then
> repacking all but the head into a list.

Aside: iterator unpacking is more general than just head/tail unpacking.

>>> a, b, *var, c, d, e = range(10) 
>>> print(a, b, c, d, e, var)
0 1 7 8 9 [2, 3, 4, 5, 6]


You are jumping to conclusions about implementation details which aren't 
supported by the visible behaviour. What evidence do you have that 
iterator unpacking creates a tuple first and then converts it to a list?


> It may be somewhat counter-intuitive to think of this as a type
> constraint, since python is after all a weakly-typed language. 

The usual test of a weakly-typed language is that "1"+1 succeeds (and 
usually gives 2), as in Perl but not Python. I believe you are confusing 
weak typing with dynamic typing, a common mistake.


[...]
> The aim of this PEP, is that this type-constraint syntax is expanded
> upon. We should be careful here to distinguish with providing optional
> type constraints throughout python as a whole; this is not our aim.

Iterator unpacking is no more about type constraints than is len().



-- 
Steven

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

#17424

On Sun, Dec 18, 2011 at 11:59 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> The usual test of a weakly-typed language is that "1"+1 succeeds (and
> usually gives 2), as in Perl but not Python. I believe you are confusing
> weak typing with dynamic typing, a common mistake.

I'd go stronger than "usually" there. If "1"+1 results in "11", then
that's not weak typing but rather a convenient syntax for
stringification - if every object can (or must) provide a to-string
method, and concatenating anything to a string causes it to be
stringified, then it's still strongly typed.

Or is a rich set of automated type-conversion functions evidence of
weak typing? And if so, then where is the line drawn - is upcasting of
int to float weak?

ChrisA

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

#17428

On Sun, 18 Dec 2011 13:45:35 +1100, Chris Angelico wrote:

> On Sun, Dec 18, 2011 at 11:59 AM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> The usual test of a weakly-typed language is that "1"+1 succeeds (and
>> usually gives 2), as in Perl but not Python. I believe you are
>> confusing weak typing with dynamic typing, a common mistake.
> 
> I'd go stronger than "usually" there. If "1"+1 results in "11", then
> that's not weak typing but rather a convenient syntax for
> stringification - if every object can (or must) provide a to-string
> method, and concatenating anything to a string causes it to be
> stringified, then it's still strongly typed.


For what it's worth, Wikipedia's article on type systems gives Javascript 
as an example of weak typing because it converts "1"+1 to "11". I agree 
with them.

http://en.wikipedia.org/wiki/Type_system

I think that weak and strong typing aren't dichotomies, but extremes in a 
continuum. Assembly languages are entirely weak, since everything is 
bytes and there are no types to check; some academic languages may be 
entire strong; but most real-world languages include elements of both. 
Most commonly coercing ints to floats.

Chris Smith's influence article "What To Know Before Debating Type 
Systems" goes further, suggesting that weak and strong typing are 
meaningless terms. I don't go that far, but you should read his article:

http://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/


> Or is a rich set of automated type-conversion functions evidence of weak
> typing? And if so, then where is the line drawn - is upcasting of int to
> float weak?

To my mind, the distinction that should be drawn is that if two types are 
in some sense the same *kind* of thing, then automatic conversions or 
coercions are weak evidence of weak typing. Since we consider both ints 
and floats to be kinds of numbers, mixed int/float arithmetic is not a 
good example of weak typing. But since numbers and strings are quite 
different kinds of things, mixed str/int operations is a good example of 
weak typing.

But not *entirely* different: numbers can be considered strings of 
digits; and non-digit strings can have numeric values. I don't know of 
any language that allows 1 + "one" to return 2, but such a thing wouldn't 
be impossible.


-- 
Steven

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

#17430

In article <4eed5eef$0$29979$c3e8da3$5496439d@news.astraweb.com>,
 Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:

> some academic languages may be 
> entire strong; but most real-world languages include elements of both. 
> Most commonly coercing ints to floats.

Early Fortran compilers did not automatically promote ints to floats.

> But not *entirely* different: numbers can be considered strings of 
> digits; and non-digit strings can have numeric values. I don't know of 
> any language that allows 1 + "one" to return 2, but such a thing wouldn't 
> be impossible.

It is possible for 1 + "one" to be equal to 2 in C or C++.  All it takes 
is for the string literal to be located at memory location 1.  Not 
likely, but nothing in the language prevents it.

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

#17431

On Sun, Dec 18, 2011 at 2:59 PM, Roy Smith <roy@panix.com> wrote:
> It is possible for 1 + "one" to be equal to 2 in C or C++.  All it takes
> is for the string literal to be located at memory location 1.  Not
> likely, but nothing in the language prevents it.

Not quite; 1 + "one" will be "ne", which might happen to be at memory
location 2. The data type is going to be char* (or, in a modern
compiler, const char*), not int. That said, though, I think that (in
this obscure circumstance) it would compare equal with 2. For what
that's worth. :)

ChrisA

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

#17425

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

On 12/17/2011 20:45, Chris Angelico wrote:
> I'd go stronger than "usually" there. If "1"+1 results in "11", then
> that's not weak typing but rather a convenient syntax for
> stringification - if every object can (or must) provide a to-string
> method, and concatenating anything to a string causes it to be
> stringified, then it's still strongly typed.
>
> Or is a rich set of automated type-conversion functions evidence of
> weak typing? And if so, then where is the line drawn - is upcasting of
> int to float weak?
>
> ChrisA
Sorry, I just subscribed to the list so am stepping in mid-conversation,
but "strong" vs "weak" typing does not have a particularly well-defined
meaning. There are at least three very different definitions you'll find
people use which are almost pairwise orthogonal in theory, if less so in
practice. There's a great mail to a Perl mailing list I've seen [1]
where someone lists *eight* definitions (albeit with a couple pairs of
definitions that are only slightly different).

I like to use it in the "automated conversion" sense, because I feel
like the other possible definitions are covered by other terms
(static/dynamic, and safe/unsafe). And in that sense, I think that
thinking of languages as "strong" *or* "weak" is a misnomer; it's a
spectrum. (Actually even a spectrum is simplifying things -- it's more
like a partial order.)

Something like ML or Haskell, which does not even allow integer to
double promotions, is very strong typing. Something like Java, which
allows some arithmetic conversion and also automatic stringification (a
la "1" + 1) is somewhere in the middle of the spectrum. Personally I'd
put Python even weaker on account of things such as '[1,2]*2' and '1 <
True' being allowed, but on the other hand it doesn't allow "1"+1.

Evan

[1]
http://groups.google.com/group/comp.lang.perl.moderated/msg/89b5f256ea7bfadb
(though I don't think I've seen all of those)

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

#17443

On Sat, 17 Dec 2011 21:03:01 -0600, Evan Driscoll wrote:

> Something like ML or Haskell, which does not even allow integer to
> double promotions, is very strong typing. Something like Java, which
> allows some arithmetic conversion and also automatic stringification (a
> la "1" + 1) is somewhere in the middle of the spectrum. Personally I'd
> put Python even weaker on account of things such as '[1,2]*2' and '1 <
> True' being allowed,

They are not examples of weak typing. The first is an example of operator 
overloading, the second is a side-effect of a compromise made for 
backwards compatibility.

If the first example were written:

[1, 2].repeat(2)

I expect you'd be perfectly happy with it as an unexceptional example of 
a list method: it takes an integer count, and returns a new list 
consisting of the elements of the original list repeated twice.

If it were written:

[1, 2].__mul__(2)

you'd probably raise an eyebrow at the ugliness of the method name, but 
you would be okay with the concept.

Well, that's exactly what it is in Python: the list __mul__ method 
performs sequence multiplication (repeating the contents), which 
overloads the * operator. No automatic type conversions needed, so not an 
example of weak typing.


As for comparisons between ints and True or False, that's not weak typing 
either, because True and False *are* ints: bool is a subclass of int. 
This was done purely for historical reasons: originally Python didn't 
have a bool type, and you used 0 and 1 by convention for boolean values. 
When it was decided to add a bool type, the least disruptive way to do 
this was to define it as a subclass of int.


-- 
Steven

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

#17427

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

On 12/17/2011 21:03, Evan Driscoll wrote:
> Personally I'd put Python even weaker on account of things such as
> '[1,2]*2' and '1 < True' being allowed, but on the other hand it
> doesn't allow "1"+1.

Not to mention duck typing, which under my definition I'd argue is
pretty much the weakest of typing that you can apply to structure-like
types which I can think of.

Evan

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

#17429

On Sun, Dec 18, 2011 at 2:03 PM, Evan Driscoll <edriscoll@wisc.edu> wrote:
> Sorry, I just subscribed to the list so am stepping in mid-conversation,

Welcome to the list! If you're curious as to what's happened, check
the archives:
http://mail.python.org/pipermail/python-list/

> Something like ML or Haskell, which does not even allow integer to
> double promotions, is very strong typing. Something like Java, which
> allows some arithmetic conversion and also automatic stringification (a
> la "1" + 1) is somewhere in the middle of the spectrum. Personally I'd
> put Python even weaker on account of things such as '[1,2]*2' and '1 <
> True' being allowed, but on the other hand it doesn't allow "1"+1.

But [1,2]*2 is operator overloading. The language doesn't quietly
convert [1,2] into a number and multiply that by 2, it keeps it as a
list and multiplies the list by 2.

Allowing 1 < True is weaker typing. It should be noted, however, that
"1 < True" is False, and "1 > True" is also False. The comparison
doesn't make much sense, but it's not an error.

ChrisA

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

#17433

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

On 12/17/2011 21:42, Chris Angelico wrote:
> Welcome to the list! If you're curious as to what's happened, check
> the archives:
> http://mail.python.org/pipermail/python-list/
Thanks! Incidentally, is there a good way to respond to the original
post in this thread, considering it wasn't delivered to me?

> But [1,2]*2 is operator overloading. The language doesn't quietly
> convert [1,2] into a number and multiply that by 2, it keeps it as a
> list and multiplies the list by 2.
>
> Allowing 1 < True is weaker typing. It should be noted, however, that
> "1 < True" is False, and "1 > True" is also False. The comparison
> doesn't make much sense, but it's not an error.
I see where you're coming from, especially as I wouldn't consider
overloading a function on types (in a language where that phrase makes
sense) moving towards weak typing either. Or at least I wouldn't have
before this discussion... At the same time, it seems a bit
implementationy. I mean, suppose '1' were an object and implemented
__lt__. Does it suddenly become not weak typing because of that?

(The other thing is that I think strong vs weak is more subjective than
many of the other measures. Is '1 < True' or '"1"+1' weaker? I think it
has a lot to do with how the operations provided by the language play to
your expectations.)

On 12/17/2011 22:05, Chris Angelico wrote:
> Not quite; 1 + "one" will be "ne", which might happen to be at memory
> location 2. The data type is going to be char* (or, in a modern
> compiler, const char*), not int. 
I'm not quite sure I'd say that it could be 2, exactly, but I definitely
disagree with this... after running 'int x = 5, *p = &x' would you say
that "p is 5"? (Assume &x != 5.) 1+"one" *points to* "ne", but it's
still a pointer.

Evan

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

#17435

On Sun, Dec 18, 2011 at 3:43 PM, Evan Driscoll <edriscoll@wisc.edu> wrote:
> On 12/17/2011 21:42, Chris Angelico wrote:
>> Welcome to the list! If you're curious as to what's happened, check
>> the archives:
>> http://mail.python.org/pipermail/python-list/
> Thanks! Incidentally, is there a good way to respond to the original
> post in this thread, considering it wasn't delivered to me?

I don't know of a way, but this works. It's all part of the same thread.

> I mean, suppose '1' were an object and implemented
> __lt__. Does it suddenly become not weak typing because of that?

Is it weak typing to overload a function?

//C++ likes this a lot.
int foo(int x,int y) {return x*3+y;}
double foo(double x,double y) {return x*3+y;}

This is definitely making the term "strongly typed language" fairly useless.

> (The other thing is that I think strong vs weak is more subjective than
> many of the other measures. Is '1 < True' or '"1"+1' weaker? I think it
> has a lot to do with how the operations provided by the language play to
> your expectations.)

+1. My expectations are:
1) The Boolean value "True" might be the same as a nonzero integer, or
might not; it would make sense to use inequality comparisons with
zero, MAYBE, but not with 1. So I don't particularly care what the
language does with "1 < True", because it's not something that I would
normally do.
2) "1"+1, in any high level language with an actual string type, I
would expect to produce "11". It makes the most sense this way; having
it return 2 means there's a special case where the string happens to
look like a number - meaning that " 1"+1 is different from "1"+1. That
just feels wrong to me... but I'm fully aware that many other people
will disagree.

Yep, it's pretty subjective.

> On 12/17/2011 22:05, Chris Angelico wrote:
>> Not quite; 1 + "one" will be "ne", which might happen to be at memory
>> location 2. The data type is going to be char* (or, in a modern
>> compiler, const char*), not int.
> I'm not quite sure I'd say that it could be 2, exactly, but I definitely
> disagree with this... after running 'int x = 5, *p = &x' would you say
> that "p is 5"? (Assume &x != 5.) 1+"one" *points to* "ne", but it's
> still a pointer.

Point. I stand corrected. I tend to think of a char* as "being" the
string, even though technically it only points to the beginning of it;
it's the nearest thing C has to a string type. (To be honest, it's
still a lot better than many high level languages' string types for
certain common operations - eg trimming leading whitespace is pretty
efficient on a PSZ.) In your example, p would be some integer value
that is the pointer, but *p is 5. However, there's really no syntax in
C to say what the "string value" is.

ChrisA

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

#17458

On Dec 18, 1:59 am, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> On Sat, 17 Dec 2011 06:38:22 -0800, Eelco wrote:
> > Type constraints:
>
> > In case the asterisk is not used to signal unpacking, but rather to
> > signal packing, its semantics is essentially that of a type constraint.
>
> "Type constraint" normally refers to type restrictions on *input*: it is
> a restriction on what types are accepted. When it refers to output, it is
> not normally a restriction, therefore "constraint" is inappropriate.
> Instead it is normally described as a coercion, cast or conversion.
> Automatic type conversions are the opposite of a constraint: it is a
> loosening of restrictions. "I don't have to use a list, I can use any
> sequence or iterator".

Casts or conversions are a runtime concept; im talking about
declarations. That seems to be the source of your confusion.

> In iterator unpacking, it is the *output* which is a list, not a
> restriction on input: in the statement:
>
> head, *tail = sequence
>
> tail may not exist before the assignment, and so describing this as a
> constraint on the type of tail is completely inappropriate.

Yes, the variable tail is being (re)declared here. Thats exactly why I
call it a type constraint. Im not sure what the CS books have to say
on the matter, I guess this use of the term entered my lexicon through
the C# developer team. Either way, you seem to be the only one who
does not grok my intended meaning, so I suggest you try reading it
again.

> > The statement:
>
> >     head, tail = sequence
>
> > Signifies regular unpacking. However, if we add an asterisk, as in:
>
> >     head, *tail = sequence
>
> > We demand that tail not be just any python object, but rather a list.
>
> We don't demand anything, any more than when we say:
>
> for x in range(1, 100):
>
> we "demand" that x is not just any python object, but rather an int.
>
> Rather, we accept what we're given: in case of range and the for loop, we
> are given an int. In the case of extended tuple unpacking, we are given a
> list.

for x in range is syntactic sugar for a series of assignments to x; x
is an unconstrained variable that will indeed take anything it gets;
the semantics of what comes after 'x' does in no way depend on x
itself. head, tail = l and head, *tail = l mean something completely
different, and the only difference is a constraint placed on tail,
which forces the semantics to be different; the righthand side, or
what is to be assigned, is identical. Of course one can just regard it
as syntactic sugar for head, tail = unpackheadandtailaslist(l); but
the syntactic sugar achieves that same end through a type constraint
on tail. Really.

> You are jumping to conclusions about implementation details which aren't
> supported by the visible behaviour. What evidence do you have that
> iterator unpacking creates a tuple first and then converts it to a list?

You are jumping to conclusions about my opinion which aren't supported
by my visible behaviour. What evidence do you have that I ever even
said any such thing?

> > The aim of this PEP, is that this type-constraint syntax is expanded
> > upon. We should be careful here to distinguish with providing optional
> > type constraints throughout python as a whole; this is not our aim.
>
> Iterator unpacking is no more about type constraints than is len().

Because you wish to keep nitpicking about my usage of the term 'type
constraint' (even though you have not introduced an alternative term
yourself), or because you actually disagree with the content of my
message?

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

#17466

On Sun, 18 Dec 2011 06:13:37 -0800, Eelco wrote:

> Casts or conversions are a runtime concept; im talking about
> declarations. That seems to be the source of your confusion.

Everything in Python happens at runtime, apart from compilation of source 
code into byte code. Python doesn't have declarations. Even class and def 
are statements which happen at runtime, not declarations which happen at 
compile time.

Your proposal will be no different: if it happens, it will happen at 
runtime.


[...]
> I guess this use of the term entered my lexicon through the
> C# developer team. Either way, you seem to be the only one who does not
> grok my intended meaning, so I suggest you try reading it again.

I grok your *intended* meaning. I also grok that you are using the wrong 
words to explain your intended meaning.

"head, *tail = iterable" is not a declaration in Python. It is not a type 
conversion, or a constraint, or a cast. It is an iterator unpacking 
operation. It is syntactic sugar for something similar to this:

tmp = iter(iterable)
head = next(tmp)
tail = []
try:
    while True:
        tail.append(next(tmp))
except StopIteration:
    pass
del tmp


The only constraint is on the *input* to the operation: the right hand 
side object must obey the iterator protocol. The only conversion (if we 
want to call it such) is that an iterator object is created by the right 
hand side object.

[...]
> head, tail = l and head, *tail = l mean something completely different,

They are both iterator unpacking, and therefore by definition not 
"completely different". The first one is syntactic sugar for something 
like this:

tmp = iter(iterable)
head = next(tmp)
tail = next(tmp)
if tmp is not empty: raise exception
del tmp


and the second as shown earlier. Clearly they are quite similar: the only 
difference is that in the first case, the right hand side must have 
exactly two items, while in the second case, the right hand side can have 
an arbitrary number of items.


> and the only difference is a constraint placed on tail, which forces the
> semantics to be different; the righthand side, or what is to be
> assigned, is identical. Of course one can just regard it as syntactic
> sugar for head, tail = unpackheadandtailaslist(l); but the syntactic
> sugar achieves that same end through a type constraint on tail. Really.

All the words are in English, but I have no understanding of what you are 
trying to say here. What is unpackheadandtailaslist and how does it 
differ from actual unpacking in Python?


>> You are jumping to conclusions about implementation details which
>> aren't supported by the visible behaviour. What evidence do you have
>> that iterator unpacking creates a tuple first and then converts it to a
>> list?
> 
> You are jumping to conclusions about my opinion which aren't supported
> by my visible behaviour. What evidence do you have that I ever even said
> any such thing?

My evidence was your actual words, quoted in my post, which you deleted 
in your response.

Here they are again:

    [quote]
    This changes the semantics from normal unpacking, to unpacking 
    and then repacking all but the head into a list.
    [end quote]

In context, "this changes..." refers to extended iterator unpacking in 
the form "head, *tail" contrasted with "head, tail =...", and that it 
generates a list.

It may very well be that I have misunderstood you. If you do not intend 
the meaning that extended tuple unpacking first unpacks to a tuple and 
then re-packs to a list, then please explain what you did mean.


>> > The aim of this PEP, is that this type-constraint syntax is expanded
>> > upon. We should be careful here to distinguish with providing
>> > optional type constraints throughout python as a whole; this is not
>> > our aim.
>>
>> Iterator unpacking is no more about type constraints than is len().
> 
> Because you wish to keep nitpicking about my usage of the term 'type
> constraint' (even though you have not introduced an alternative term
> yourself), or because you actually disagree with the content of my
> message?

I don't think much about your proposal. I think it is unnecessary, based 
on a profound misunderstanding of how Python actually operates, badly 
explained using inappropriate terms, and the syntax you propose is ugly.


-- 
Steven

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

#17467

On 18 dec, 18:03, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> On Sun, 18 Dec 2011 06:13:37 -0800, Eelco wrote:
> > Casts or conversions are a runtime concept; im talking about
> > declarations. That seems to be the source of your confusion.
>
> Everything in Python happens at runtime, apart from compilation of source
> code into byte code. Python doesn't have declarations. Even class and def
> are statements which happen at runtime, not declarations which happen at
> compile time.


Of course it will have runtime effects; and compile/interpret-time
effects too. You said as much yourself: 'Everything in Python happens
at runtime, apart from compilation of source'.

Python *does* have declarations. Even though they may not be called
such in the documentation (dunno, havnt checked) the current use of *
and ** when not signifying collectiong UNpacking, is an annotation to
the declaration of the symbol that comes after it. In this case, a
constraint-on / specification-of the type of the object that the
variable symbol may bind; a list or tuple, depending on the context.

> Your proposal will be no different: if it happens, it will happen at
> runtime.

At least something we agree upon; all im proposing is an alternative
syntax for something thats already there. Lets be pragmatic and agree
to disagree on what it is that is already there, or what it ought to
be called. Because frankly, this has detracted enough already from
what it is I do want to discuss.

> [snipped staements of the obvious]
>
> and the second as shown earlier. Clearly they are quite similar: the only
> difference is that in the first case, the right hand side must have
> exactly two items, while in the second case, the right hand side can have
> an arbitrary number of items.

Oh great, you found another semantic hair to split. Yes, they are
quite similar. Nonetheless, any python implementation that would
confuse the two behaviors would be considered badly bugged.


> > and the only difference is a constraint placed on tail, which forces the
> > semantics to be different; the righthand side, or what is to be
> > assigned, is identical. Of course one can just regard it as syntactic
> > sugar for head, tail = unpackheadandtailaslist(l); but the syntactic
> > sugar achieves that same end through a type constraint on tail. Really.
>
> All the words are in English, but I have no understanding of what you are
> trying to say here. What is unpackheadandtailaslist and how does it
> differ from actual unpacking in Python?

I have the impression you are not even trying then. Google 'syntactic
sugar'. It means 'semantically identical way of putting things', in
short. That tells you everything you need to know about
unpackheadandtailaslist: nothing.

> >> You are jumping to conclusions about implementation details which
> >> aren't supported by the visible behaviour. What evidence do you have
> >> that iterator unpacking creates a tuple first and then converts it to a
> >> list?
>
> > You are jumping to conclusions about my opinion which aren't supported
> > by my visible behaviour. What evidence do you have that I ever even said
> > any such thing?
>
> My evidence was your actual words, quoted in my post, which you deleted
> in your response.
>
> Here they are again:
>
>     [quote]
>     This changes the semantics from normal unpacking, to unpacking
>     and then repacking all but the head into a list.
>     [end quote]
>
> In context, "this changes..." refers to extended iterator unpacking in
> the form "head, *tail" contrasted with "head, tail =...", and that it
> generates a list.
>
> It may very well be that I have misunderstood you. If you do not intend
> the meaning that extended tuple unpacking first unpacks to a tuple and
> then re-packs to a list, then please explain what you did mean.

Again, where did I say it first unpacks to a tuple? As far as im aware
that only happens in the context of a function call.

> >> > The aim of this PEP, is that this type-constraint syntax is expanded
> >> > upon. We should be careful here to distinguish with providing
> >> > optional type constraints throughout python as a whole; this is not
> >> > our aim.
>
> >> Iterator unpacking is no more about type constraints than is len().
>
> > Because you wish to keep nitpicking about my usage of the term 'type
> > constraint' (even though you have not introduced an alternative term
> > yourself), or because you actually disagree with the content of my
> > message?
>
> I don't think much about your proposal. I think it is unnecessary, based
> on a profound misunderstanding of how Python actually operates, badly
> explained using inappropriate terms, and the syntax you propose is ugly.

Which is not an aswer to the question I posed; just an expression of
frustration.

Its mutual.

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

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

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

csiph-web