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

#17434

I like the spirit of this. Let's look at your examples.

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

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.

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.

-buck

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

#17436

On Sun, Dec 18, 2011 at 3:52 PM, buck <workitharder@gmail.com> wrote:
> 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.
>
> Try these on for size.
>
>     head, @tuple tail = sequence
>     def foo(@list args, @dict kwargs): pass
>     foo(@args, @kwargs)

That's reasonably clean as a concept, but it's not really quite the
same. None of these examples is the way a decorator works; each of
them requires a fundamental change to the way Python handles the rest
of the statement.

head, @tuple tail = sequence
-- Does this mean "take the second element of a two-element sequence,
pass it through tuple(), and store the result in tail"? Because, while
that might be useful, and would make perfect sense as a decorator,
it's insufficient as a replacement for current "*tail" syntax.

ChrisA

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

#17437

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

On 12/17/2011 22:52, buck wrote:
> Try these on for size.
>
>      head, @tuple tail = sequence 
>      def foo(@list args, @dict kwargs): pass 
>      foo(@args, @kwargs)
>
> For backward compatibility, we could say that the unary * is identical to @list and unary ** is identical to @dict.
>
I like this idea much more than the original one. In addition to the
arguments buck puts forth, which I find compelling, I have one more: you
go to great length to say "this isn't really type checking in any sense"
(which is true)... but then you go forth and pick a syntax that looks
almost exactly like how you name types in many languages! (In fact,
except for the fact that it's inline, the 'object :: type' syntax is
*exactly* how you name types in Haskell.)

buck's syntax still has some of the feel of "I wonder if this is type
checking" to a newbie, but much much less IMO.


I have a bigger objection with the general idea, however.It seems very
strange that you should have to specify types to use it. If the */**
syntax were removed, that would make the proposed syntax very very
unusual for Python. I could be missing something, but I can think of any
other place where you have to name a type except where the type is an
integral part of what you're trying to do. (I would not say that
choosing between tuples and lists are an integral part of dealing with
vararg functions.) If */** were to stick around, I could see 99% of
users continuing to use them. And then what has the new syntax achieved?

You can fix this if you don't require the types and just allow the user
to say "def foo(@args)" and "foo(@args)". Except... that's starting to
look pretty familiar... (Not to mention if you just omit the type from
the examples above you need another way to distinguish between args and
kwargs.)


I have one more suggestion.

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.
I certainly remember having a small amount of difficulty figuring out
what the heck * and ** did the first time I encountered them.

This would suggest perhaps some keywords might be called for instead of
operators. In the grand scheme of things the argument packing and
unpacking are not *all* that common, so I don't think the syntactic
burden would be immense. The bigger issue, of course, would be picking
good words.

This also helps with the issue above. Let's say we'll use 'varargs' and
'kwargs', though the latter too well-ingrained in code to steal. (I
don't want to get too much into the debate over *what* word to choose.
Also these don't match the 'head, *tail = l' syntax very well.) Then we
could say:
  def foo(varargs l, kwargs d):
      bar(varargs l, kwargs d)
and varargs would be equivalent to * and kwargs would be equivalent to
**. But then you could also say
  def foo(varargs(list) l, kwargs(dict) d)

Evan

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

#17439

On Sat, 17 Dec 2011 23:33:27 -0600, 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.

You're coming in late to the conversation, but that was literally the 
second thing pointed out by the original poster:

    On Sun, 11 Dec 2011 11:49:23 +0100, Eelco Hoogendoorn wrote:
    > Throwing an idea for a PEP out there:
    > 
    > It strikes me that the def func(*args, **kwargs) syntax is rather
    > unpytonic. It certainly did not have that 'for line in file'
    > pythonic obviousness for me as a beginner. Plus, asterikses are
    > impossible to google for, so finding out what exactly they do more
    > or less forces you to write a forum post about it.

And rebutted. Modesty[1] prevents me from quoting myself, but here are 
some links to searches:

http://duckduckgo.com/?q=python+asterisk
http://duckduckgo.com/?q=python+*

My normal first place to look for something is Wikipedia. Enjoy it before 
SOPA kills it.

http://en.wikipedia.org/wiki/Asterisk#Programming_languages



> In the first pages
> of the four searches matching "python (function)? (star | asterisk)",

Your search looks overly complicated to me.

I'm not an expert on Google's syntax, but if you search for "python, 
optionally with function", isn't that the same as just searching for 
"python" since it will return hits either with or without "function"?


> I certainly remember having a small amount of difficulty figuring out
> what the heck * and ** did the first time I encountered them.

Answering that sort of question is what the interactive interpreter 
excels at. Suppose you see a function declared with *args as an argument, 
and you have no idea what it means. Try it and find out!

py> def spam(*args):
...     print(args, type(args))
... 
py> spam(42)
((42,), <type 'tuple'>)
py> spam(42, 23)
((42, 23), <type 'tuple'>)

Never underestimate the power of Python's introspection tools, especially 
the two simplest ones: print and type. Often you will learn more in 10 
minutes experimentation than in an hour googling.



[1] Eh, who am I fooling?

-- 
Steven

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

#17442

On Sun, Dec 18, 2011 at 6:31 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> My normal first place to look for something is Wikipedia. Enjoy it before
> SOPA kills it.
>
> http://en.wikipedia.org/wiki/Asterisk#Programming_languages

I would never expect to find this sort of thing in the article on the
asterisk; maybe I'd look on the language's article, but more likely I
would be looking for info on the language's own web site.

> On Sat, 17 Dec 2011 23:33:27 -0600, Evan Driscoll wrote:
>> In the first pages
>> of the four searches matching "python (function)? (star | asterisk)",
>
> Your search looks overly complicated to me.

I understand this to mean that he did four searches:
* python star
* python function star
* python asterisk
* python function asterisk

> Never underestimate the power of Python's introspection tools, especially
> the two simplest ones: print and type. Often you will learn more in 10
> minutes experimentation than in an hour googling.

+1 QOTW. I refer to this as "IIDPIO debugging" (Eyed Pio) - If In
Doubt, Print It Out.

ChrisA

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

#17456

In article <mailman.3787.1324197792.27778.python-list@python.org>,
 Chris Angelico <rosuav@gmail.com> wrote:

> > Never underestimate the power of Python's introspection tools, especially
> > the two simplest ones: print and type. Often you will learn more in 10
> > minutes experimentation than in an hour googling.
> 
> +1 QOTW. I refer to this as "IIDPIO debugging" (Eyed Pio) - If In
> Doubt, Print It Out.

I always knew it by the name "Ask the computer".  As in, "WTF is foo?  
Let's ask the computer!".

In addition to print and type, I'm a big fan of dir().  Often, I know an 
object has a method to do what I want, but I can't remember the name.  
For example, the other day, I was using a set (which I don't use very 
often).  I needed the method to remove an item from the set.  Faster 
than finding the right place in the docs, I just fired up an interpreter 
and typed dir(set()) at it.

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

#17457

On Mon, Dec 19, 2011 at 12:58 AM, Roy Smith <roy@panix.com> wrote:
> In addition to print and type, I'm a big fan of dir().  Often, I know an
> object has a method to do what I want, but I can't remember the name.
> For example, the other day, I was using a set (which I don't use very
> often).  I needed the method to remove an item from the set.  Faster
> than finding the right place in the docs, I just fired up an interpreter
> and typed dir(set()) at it.

That's excellent when all you need is the name. I usually have IDLE
running (all the time - which sometimes produces oddities after I
experiment with monkey-patching some module or other, and then oddly
enough, things don't work properly!!), and will snap off "help(foo)"
for any foo. Unfortunately help() is at times unhelpful, and even at
its best it's very spammy. There's no one best solution; the
successful programmer will usually have a large toolset at his
disposal.

ChrisA

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

#17475

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

On 12/18/2011 1:31, Steven D'Aprano wrote:
> And rebutted. Modesty[1] prevents me from quoting myself, but here are 
> some links to searches:
>
> http://duckduckgo.com/?q=python+asterisk
> http://duckduckgo.com/?q=python+*
OK, so if you search using the right search engine, you *might* get a
link to the Python docs. (As I pointed out in a reply to myself before,
you *do* get relevant hits with my Google searches as well, but
virtually nothing to the relevant Python documentation.)

My thinking is borne out; I asked a friend who didn't know what it did
to find out, and he went to Google with the search "python 'starred
argument'", which he said led to moderately helpful results, but again
none from the actual Python docs.

> My normal first place to look for something is Wikipedia. Enjoy it before 
> SOPA kills it.
>
> http://en.wikipedia.org/wiki/Asterisk#Programming_languages
I might think to look at the Wikipedia article for *Python* (which, by
the way, doesn't help); looking at the wikipedia page for *asterisk*
wouldn't even enter my mind.


> Your search looks overly complicated to me.
>
> I'm not an expert on Google's syntax, but if you search for "python, 
> optionally with function", isn't that the same as just searching for 
> "python" since it will return hits either with or without "function"?
Chris Angelico's interpretation is correct: I did four searches, "python
function star", "python function asterisk", "python star", and "python
asterisk".

Evan

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

#17512

Evan Driscoll <edriscoll@wisc.edu> wrote:

>> I'm not an expert on Google's syntax, but if you search for "python, 
>> optionally with function", isn't that the same as just searching for 
>> "python" since it will return hits either with or without "function"?
> Chris Angelico's interpretation is correct: I did four searches, "python
> function star", "python function asterisk", "python star", and "python
> asterisk".
> 

Using www.google.com:

"python function star": first hit is: http://farmdev.com/thoughts/24/what-
does-the-def-star-variable-or-def-asterisk-parameter-syntax-do-in-python-/

"python function asterisk": first hit is: 
http://www.technovelty.org/code/python/asterisk.html

"python asterisk": the first hit I get is 
http://www.technovelty.org/code/python/asterisk.html

"python star" is the only useless one of those giving me two hits for star 
pathfinding algorithms, one about the BNF used in Python's documentation, 
and a Daily Mail article about John Cleese and Eric Idle.

-- 
Duncan Booth http://kupuguy.blogspot.com

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

#17441

On Sat, 17 Dec 2011 23:33:27 -0600, Evan Driscoll wrote:

> This would suggest perhaps some keywords might be called for instead of
> operators.

The barrier to new keywords in Python is very high. Not going to happen 
for something that already has perfectly good syntax already familiar to 
Python and Ruby programmers. Might else well try to get C and Java to 
stop using "..." (ellipses).


> In the grand scheme of things the argument packing and
> unpacking are not *all* that common, so I don't think the syntactic
> burden would be immense.

The burden is that you complicate the compiler and reduce the pool of 
useful names available to the programmer. To be useful, the keywords need 
to be short, meaningful and memorable -- which means they're already used 
in code, which you will break needlessly.

With operators that otherwise would be illegal, the programmer doesn't 
need to learn about varargs until they need to. With keywords, the 
programmer needs to learn "you can't use varargs or kwargs as variable 
names" practically from day 1.


> But then you could also say
>   def foo(varargs(list) l, kwargs(dict) d)

So you're not just adding keywords, you're adding new syntax: something 
which looks like a function call, but isn't a function call. Another 
feature which the programmer has to learn just to be able to read Python 
source code -- and one which almost certainly is going to clash with 
function annotations as people start using them.

I'm going to pose the same question to you I have already posed to Eelco: 
in your proposal, what happens if the caller has shadowed the list built-
in? Does argument l become a built-in list, or does it become whatever 
type list is currently bound to?

Some more questions:

Can varargs accepted arbitrary callables, or only a fixed set of known 
types?

How does this differ from what can be done with annotations?


-- 
Steven

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

#17473

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

On 12/18/2011 2:36, Steven D'Aprano wrote:
> The barrier to new keywords in Python is very high. Not going to
> happen for something that already has perfectly good syntax already
> familiar to Python and Ruby programmers. Might else well try to get C
> and Java to stop using "..." (ellipses).
I agree to some extent; I did say my suggestion was somewhat an effort
in brainstorming. (Though I would point out that, if you accept the
premise of this PEP suggestion, "perfectly good" only sort of applies.)

> The burden is that you complicate the compiler and reduce the pool of 
> useful names available to the programmer. To be useful, the keywords need 
> to be short, meaningful and memorable -- which means they're already used 
> in code, which you will break needlessly.
OTOH, it wouldn't be the first time it was done. For instance, 'with'.

> With operators that otherwise would be illegal, the programmer doesn't 
> need to learn about varargs until they need to. With keywords, the 
> programmer needs to learn "you can't use varargs or kwargs as variable 
> names" practically from day 1.
Yes, but it's not exactly a hard lesson. I can't think of any time where
you'd have ambiguous syntax, so misuse could always produce a good error
message. And keyword highlighting is something that basically all
editors can do well... so unless you're opposed to using an editor more
advanced than Notepad, you'll type in "varargs", it'll turn purple or
whatever, and you'll go "oh that's a keyword."


> So you're not just adding keywords, you're adding new syntax: something 
> which looks like a function call, but isn't a function call.
Well, almost by definition these proposals consider adding syntax.

> I'm going to pose the same question to you I have already posed to Eelco: 
> in your proposal, what happens if the caller has shadowed the list built-
> in? Does argument l become a built-in list, or does it become whatever 
> type list is currently bound to?
>
> Some more questions:
>
> Can varargs accepted arbitrary callables, or only a fixed set of known 
> types?
>
> How does this differ from what can be done with annotations?
These are questions I don't feel I can answer very well. I was giving my
thoughts on what I would do or consider doing with the proposal assuming
the fundamental idea is sound. Whether it should be accepted at all is a
matter for someone else. :-)

Evan

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

#17487

On Sun, 18 Dec 2011 13:47:46 -0600, Evan Driscoll wrote:

[...]
> so unless you're opposed to using an editor more
> advanced than Notepad, you'll type in "varargs", it'll turn purple or
> whatever, and you'll go "oh that's a keyword."

Not everybody uses editors more advanced than Notepad. Even those who do 
may not have an editor that understands Python keywords, or has an 
obsolete list of keywords (my editor of choice doesn't know about 
NotImplementedError). Or they're ssh'ed into a customer's server half-way 
across the world and using `ed` because that's the only thing available.

The point is not that there can never been more keywords in Python, but 
that the burden of proof is on those asking for new keywords. By default, 
the status quo wins:

http://www.boredomandlaziness.org/2011/02/status-quo-wins-stalemate.html


-- 
Steven

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

#17490

On Dec 18, 7:26 pm, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> Not everybody uses editors more advanced than Notepad.
And they have no excuse for NOT using a better one. Well, except for a
"foolish consistency" that is!

> Even those who do
> may not have an editor that understands Python keywords, or has an
> obsolete list of keywords (my editor of choice doesn't know about
> NotImplementedError).

Are you kidding me? Any editor that is not smart enough to do...
>>> import keyword
>>> pyKeyWords = keyword.kwlist
... needs to be thrown out the window.

And let's not forget that Python even ships with an IDE called IDLE.
As poorly written as IDLE's code may be, at least it is smart enough
to find the current keyword list.

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

#17524

On 12/18/2011 8:16 PM, Rick Johnson wrote:
> On Dec 18, 7:26 pm, Steven D'Aprano <steve
> +comp.lang.pyt...@pearwood.info> wrote:
>> Not everybody uses editors more advanced than Notepad.
> And they have no excuse for NOT using a better one. Well, except for a
> "foolish consistency" that is!
But what about the example he gave about being logged into a customer's
machine with only ed available? I suppose such fools would not be worthy
of your business.

-- 
CPython 3.2.2 | Windows NT 6.1.7601.17640 | Thunderbird 7.0

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

#17533

In article <mailman.3827.1324331890.27778.python-list@python.org>,
 Andrew Berg <bahamutzero8825@gmail.com> wrote:

> But what about the example he gave about being logged into a customer's
> machine with only ed available? I suppose such fools would not be worthy
> of your business.

The customer is always right.  Especially when the support contract is 
big enough to make or break your quarter.

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

#17535

On 12/19/2011 7:18 PM, Roy Smith wrote:
> Sorry, I wasn't meaning to imply support for the syntax proposal.  Just
> reacting to the (seemingly unrelated) comment that a customer with
> foolish access policies would not be worthy of your business. 
It was directed at Rick, and by "your", I was referring to him
specifically, as that is the kind of attitude I might expect him to show.

-- 
CPython 3.2.2 | Windows NT 6.1.7601.17640 | Thunderbird 7.0

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

#17546

On Dec 20, 7:57 am, Andrew Berg <bahamutzero8...@gmail.com> wrote:
> But what about the example he gave about being logged into a customer's
> machine with only ed available? I suppose such fools would not be worthy
> of your business.

Do you mean directly editing the source code on a production machine?
Because that's pretty much the only scenario I can come up with where
that's plausible.

If I was doing that, _I_ wouldn't be worth doing business with.

So you only have ssh & ed: at the very least you should be making
changes against your local copy, TESTING THEM, and then copy&paste
directly onto the remote box.

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

#17553

On 12/19/2011 9:38 PM, alex23 wrote:
> Do you mean directly editing the source code on a production machine?
> Because that's pretty much the only scenario I can come up with where
> that's plausible.
You'd have to ask Steven D'Aprano; it was his scenario.

-- 
CPython 3.2.2 | Windows NT 6.1.7601.17640 | Thunderbird 7.0

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

#17615

On Mon, 19 Dec 2011 19:38:52 -0800, alex23 wrote:

> On Dec 20, 7:57 am, Andrew Berg <bahamutzero8...@gmail.com> wrote:
>> But what about the example he gave about being logged into a customer's
>> machine with only ed available? I suppose such fools would not be
>> worthy of your business.
> 
> Do you mean directly editing the source code on a production machine?
> Because that's pretty much the only scenario I can come up with where
> that's plausible.
>
> If I was doing that, _I_ wouldn't be worth doing business with.
> 
> So you only have ssh & ed: at the very least you should be making
> changes against your local copy, TESTING THEM, and then copy&paste
> directly onto the remote box.

Come on guys, you're treating a throw-away example *way* too seriously.

If we're going to hypothesis a customer so insane to only have ed 
installed on their system[1], chances are they've specified some crazy 
rule like "You May Not Copy Our Precious, Precious Source Code Onto 
Another Machine Because That's Copyright Theft". Or whatever. Spend 15 
minutes on The Daily WTF and you'll see war stories far more crazy than 
that.

The point I was making is that in the real world, sometimes you don't 
have the luxury of using the right tool for the job, but have to make do 
with whatever you have. Languages shouldn't depend on advanced editor 
features or special keyboards -- that way leads to ColorForth and APL.



[1] Possibly because ed is the standard Unix editor.
http://www.gnu.org/fun/jokes/ed.msg.html


-- 
Steven

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

#17495

On Sun, Dec 18, 2011 at 6:26 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Sun, 18 Dec 2011 13:47:46 -0600, Evan Driscoll wrote:
>
> [...]
>> so unless you're opposed to using an editor more
>> advanced than Notepad, you'll type in "varargs", it'll turn purple or
>> whatever, and you'll go "oh that's a keyword."
>
> Not everybody uses editors more advanced than Notepad. Even those who do
> may not have an editor that understands Python keywords, or has an
> obsolete list of keywords (my editor of choice doesn't know about
> NotImplementedError).

Probably because NotImplementedError is not a keyword.

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

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

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

csiph-web