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

#17484

On Dec 17, 10:52 pm, buck <workithar...@gmail.com> wrote:
> [...]
> As for the separator, let's examine the available ascii punctuation. Excluding valid variable characters, whitespace, and operators, we have:
>
> ! -- ok.
No, there are better uses for that char.

> " -- can't use this. Would look like a string.
> # -- no. Would looks like a comment.
> $ -- ok.
No, there are better uses for that char.

> : -- ok, maybe. Seems confusing in a colon-terminated statement.
dear god no!

> ; -- no, just no.
> ? -- ok.
No, there are better uses for that char.

> @ -- ok.
YES!

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

#17729

I agree with the OP that the current syntax is confusing.  The issue is, the 
meaning of * is context-dependent.

Why not this:

Func (*args) == Func (unpack (args))

def Func (*args) == Func (pack (args))

That seems very clear IMO

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

#17730

On Thu, 22 Dec 2011 06:49:16 -0500, Neal Becker wrote:

> I agree with the OP that the current syntax is confusing.  The issue is,
> the meaning of * is context-dependent.

Here you are complaining about an operator being "confusing" because it 
is context-dependent, in a post where you strip all context except the 
subject line and expect us to still understand what you're talking about. 
There's a lesson there, I'm sure.


* is context dependent. You know what else is context dependent? Well, 
most things. But in particular, parentheses. Clearly they must be 
"confusing" too. So how about we say:

class MyClass superclasslist A, B C:
    def method argumentlist self, x, y:
        t = tuple 1, 2 tuple 3, 4 endtuple endtuple
        return group x + y endgroup * group x - y endgroup


Much less confusing!



-- 
Steven

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

#17732

On Fri, Dec 23, 2011 at 12:12 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> class MyClass superclasslist A, B C:
>    def method argumentlist self, x, y:
>        t = tuple 1, 2 tuple 3, 4 endtuple endtuple
>        return group x + y endgroup * group x - y endgroup
>
>
> Much less confusing!

A definite improvement. However, I fear that the numerals "1", "2",
etc are far too vague. In some contexts, the abuttal of two such
numerals results in a larger number by a factor of 10, while in
others, the factor is 8, or 16, or 2. This must not be. We need an
unambiguous representation of integers.

Also, I think we should adopt an existing standard [1]. This is
generally a good idea.

class MyClass superclasslist A, B C:
   def method argumentlist self, x, y:
       t = tuple summer's day, proud pony tuple
          sum of honest purse and fellow, large proud town
       endtuple endtuple
       return product of group sum of x and y endgroup and group
difference between x and y endgroup

You will find this a vast improvement.

ChrisA

[1] http://shakespearelang.sourceforge.net/report/shakespeare/shakespeare.html#SECTION00045000000000000000
or http://tinyurl.com/6sycv

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

#17734

On 22/12/11 14:12:57, Steven D'Aprano wrote:
> On Thu, 22 Dec 2011 06:49:16 -0500, Neal Becker wrote:
>
>> I agree with the OP that the current syntax is confusing.  The issue is,
>> the meaning of * is context-dependent.
>
> Here you are complaining about an operator being "confusing" because it
> is context-dependent, in a post where you strip all context except the
> subject line and expect us to still understand what you're talking about.
> There's a lesson there, I'm sure.
>
>
> * is context dependent. You know what else is context dependent? Well,
> most things. But in particular, parentheses. Clearly they must be
> "confusing" too. So how about we say:
>
> class MyClass superclasslist A, B C:
>      def method argumentlist self, x, y:
>          t = tuple 1, 2 tuple 3, 4 endtuple endtuple
>          return group x + y endgroup * group x - y endgroup
>
>
> Much less confusing!

How about:

<class name="MyClass" superclasses="A, B, C">
     <def name="method" arguments="self, x, y">
         <let target="t">
             <tuple>
                 <te>1</te>
                 <te>2</te>
                 <te><tuple><te>3</te><te>4</te></tuple></te>
             </tuple>
         </let>
         <return>
             <multiply>
                 <add><var>x</var><var>x</var></add>
                 <subtract><var>x</var><var>x</var></subtract>
             </multiply>
         </return>
     </def>
</class>

More more readable!  And it's a standard!

:-)

-- HansM

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

#17735

On Fri, Dec 23, 2011 at 1:13 AM, Hans Mulder <hansmu@xs4all.nl> wrote:
> How about:
>
> <class name="MyClass" superclasses="A, B, C">
> ...
> </class>
>
> More more readable!  And it's a standard!

Unfortunately it's not Pythonic, because indentation is insignificant.
We need to adopt a more appropriate form. Eliminate all the </spam>
tags and use indentation to mark the ends of elements.

ChrisA
PS. Brilliant, sir, brilliant! I take off my cap to you.

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

#17738

Chris Angelico wrote:

> On Fri, Dec 23, 2011 at 1:13 AM, Hans Mulder <hansmu@xs4all.nl> wrote:
>> How about:
>>
>> <class name="MyClass" superclasses="A, B, C">
>> ...
>> </class>
>>
>> More more readable!  And it's a standard!
> 
> Unfortunately it's not Pythonic, because indentation is insignificant.

Easy-peasy:

     <def name="method" arguments="self, x, y">
         <indent>    </indent><let target="t">

	Mel.

> We need to adopt a more appropriate form. Eliminate all the </spam>
> tags and use indentation to mark the ends of elements.
> 
> ChrisA
> PS. Brilliant, sir, brilliant! I take off my cap to you.

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

#17847

On Dec 22, 2:12 pm, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> On Thu, 22 Dec 2011 06:49:16 -0500, Neal Becker wrote:
> > I agree with the OP that the current syntax is confusing.  The issue is,
> > the meaning of * is context-dependent.
>
> Here you are complaining about an operator being "confusing" because it
> is context-dependent, in a post where you strip all context except the
> subject line and expect us to still understand what you're talking about.
> There's a lesson there, I'm sure.
>
> * is context dependent. You know what else is context dependent? Well,
> most things. But in particular, parentheses. Clearly they must be
> "confusing" too. So how about we say:
>
> class MyClass superclasslist A, B C:
>     def method argumentlist self, x, y:
>         t = tuple 1, 2 tuple 3, 4 endtuple endtuple
>         return group x + y endgroup * group x - y endgroup
>
> Much less confusing!
>
> --
> Steven

Context dependence is not something to be avoided at all costs, but
all else being equal, less is certainly more. The general concept of
grouping thing together which parenthesis is an extremely pervasive
one in programming, and thus deserves its own set of context-dependent
rules. Packing and unpacking collections is far, far more rare, and
thus a form that requires you to write more but remember less is
certainly relatively favorable.

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

#17884

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

> Context dependence is not something to be avoided at all costs, but all
> else being equal, less is certainly more. The general concept of
> grouping thing together which parenthesis is an extremely pervasive one
> in programming, and thus deserves its own set of context-dependent
> rules. Packing and unpacking collections is far, far more rare, 

Not in Python, where it is a very common idiom.


> and thus
> a form that requires you to write more but remember less is certainly
> relatively favorable.

Not in Python, where iteration is a fundamental idiom and packing/
unpacking is a basic syntax construct precisely because the designer of 
the language expects it to be common and encourages its use. There are 
built-in functions designed to be used with unpacking operations, e.g. 
enumerate and zip:

for i, obj in enumerate(sequence): ...
for a, b in zip(obj, range(100)): ...


-- 
Steven

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

#17909

On Dec 25, 1:45 pm, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> On Sat, 24 Dec 2011 06:54:07 -0800, Eelco wrote:
> > Context dependence is not something to be avoided at all costs, but all
> > else being equal, less is certainly more. The general concept of
> > grouping thing together which parenthesis is an extremely pervasive one
> > in programming, and thus deserves its own set of context-dependent
> > rules. Packing and unpacking collections is far, far more rare,
>
> Not in Python, where it is a very common idiom.

I know we are talking about python; it was me that put that in the
title, after all. I know python makes more use of this than some
languages (and less than others; I wouldnt suggest such a verbose
syntax for a functional language for instance). Anyway,  braces are
used at least an order of magnitude more than collection packing/
unpacking in typical code.

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

#17918

On Sun, 25 Dec 2011 06:55:28 -0800, Eelco wrote:

> Anyway,  braces are used at
> least an order of magnitude more than collection packing/ unpacking in
> typical code.

That's a wild and unjustified claim. Here's a quick and dirty test, using 
the standard library as an example of typical idiomatic code:

[steve@orac ~]$ cd /usr/lib/python2.6
[steve@orac python2.6]$ grep "[*]args" *.py | wc -l
270
[steve@orac python2.6]$ grep "{" *.py | wc -l
550

Doesn't look like a factor of 10 difference to me.


And from one of my projects:

[steve@orac src]$ grep "[*]args" *.py | wc -l
267
[steve@orac src]$ grep "{" *.py | wc -l
8



-- 
Steven

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

#17978

On Dec 25, 5:15 pm, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> On Sun, 25 Dec 2011 06:55:28 -0800, Eelco wrote:
> > Anyway,  braces are used at
> > least an order of magnitude more than collection packing/ unpacking in
> > typical code.
>
> That's a wild and unjustified claim. Here's a quick and dirty test, using
> the standard library as an example of typical idiomatic code:
>
> [steve@orac ~]$ cd /usr/lib/python2.6
> [steve@orac python2.6]$ grep "[*]args" *.py | wc -l
> 270
> [steve@orac python2.6]$ grep "{" *.py | wc -l
> 550
>
> Doesn't look like a factor of 10 difference to me.

Now try it without changing the subject from round braces to
everything but round braces.

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

#17980

On Tue, Dec 27, 2011 at 7:39 AM, Eelco <hoogendoorn.eelco@gmail.com> wrote:
> Now try it without changing the subject from round braces to
> everything but round braces.

Around here, the term "braces" means the curly ones - { and } - that
delimit blocks of code in C, and dictionaries/sets in Python.
"Brackets" may be what you're looking for, if you mean all of ()[]{}.
Or if you just mean (), they're called "parentheses".

If your point is that parens are used more often than
packing/unpacking, that's almost certainly true, since function calls
(including method invocations) are so prevalent in pretty much any
code. But what does that prove?

ChrisA

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

#17983

On Dec 26, 10:01 pm, Chris Angelico <ros...@gmail.com> wrote:
> On Tue, Dec 27, 2011 at 7:39 AM, Eelco <hoogendoorn.ee...@gmail.com> wrote:
> > Now try it without changing the subject from round braces to
> > everything but round braces.
>
> Around here, the term "braces" means the curly ones - { and } - that
> delimit blocks of code in C, and dictionaries/sets in Python.
> "Brackets" may be what you're looking for, if you mean all of ()[]{}.
> Or if you just mean (), they're called "parentheses".
>
> If your point is that parens are used more often than
> packing/unpacking, that's almost certainly true, since function calls
> (including method invocations) are so prevalent in pretty much any
> code. But what does that prove?

That proves the original point of contention: that the below* is
suboptimal language design, not because terseness always trumps
verbosity, but because commonly-used constructs (such as parenthesis
or round brackets or whatever you wish to call them) are more
deserving of the limited space in both the ascii table and your
reflexive memory, than uncommonly used ones.


*original mock code by steve:

class MyClass superclasslist A, B C:
    def method argumentlist self, x, y:
        t = tuple 1, 2 tuple 3, 4 endtuple endtuple
        return group x + y endgroup * group x - y endgroup

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

#17985

On Tue, Dec 27, 2011 at 8:51 AM, Eelco <hoogendoorn.eelco@gmail.com> wrote:
> That proves the original point of contention: that [Steve's demo code] is
> suboptimal language design, not because terseness always trumps
> verbosity, but because commonly-used constructs (such as parenthesis
> or round brackets or whatever you wish to call them) are more
> deserving of the limited space in both the ascii table and your
> reflexive memory, than uncommonly used ones.

In Magic: The Gathering R&D, they have a term (the article reporting
which I can't actually find at the moment) called "spread complexity"
or "fan complexity" - the idea being that as you fan out a booster
pack, you see a certain amount of complexity in front of you. The
designers can afford to put more complex cards in as rares than they
can as commons, because you see ten commons for every rare - so a
common factors ten times as much as a rare in spread complexity. (Mark
Rosewater, my apologies if I'm misremembering here!)

The same applies here. When you cast your eye over a program, you're
going to see certain syntactic elements a lot. Assignment, arithmetic,
blocks of code (ie indent/dedent), and function calls are all
extremely common; lambdas, the use of decorators, and exception
handling are somewhat uncommon; and metaclasses, the writing of
decorators, and reloading of modules are all quite rare.

The elements that occur frequently should be:
a) Readable and grokkable;
b) Easily typed on a regular keyboard - no using ASCII character 126
to mean negation, tyvm!
c) Make sense.

Rarer elements (and I'm not talking about xenon and plutonium here)
are allowed to have long names, obscure syntax, or even be shoved away
in odd modules (the way module reloading is in Python 3). If 0.1% of
your code is suddenly twice as large as it used to be, will you
notice? But if a new syntax adds even 5% to the mindspace requirement
of basic assignment, your code will majorly suffer.

In summary: Terseness trumps verbosity primarily for common
operations, and only when doing so does not violate rules a and c
above.

ChrisA

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

#17999

On Dec 26, 11:27 pm, Chris Angelico <ros...@gmail.com> wrote:
> On Tue, Dec 27, 2011 at 8:51 AM, Eelco <hoogendoorn.ee...@gmail.com> wrote:
> > That proves the original point of contention: that [Steve's demo code] is
> > suboptimal language design, not because terseness always trumps
> > verbosity, but because commonly-used constructs (such as parenthesis
> > or round brackets or whatever you wish to call them) are more
> > deserving of the limited space in both the ascii table and your
> > reflexive memory, than uncommonly used ones.
>
> In Magic: The Gathering R&D, they have a term (the article reporting
> which I can't actually find at the moment) called "spread complexity"
> or "fan complexity" - the idea being that as you fan out a booster
> pack, you see a certain amount of complexity in front of you. The
> designers can afford to put more complex cards in as rares than they
> can as commons, because you see ten commons for every rare - so a
> common factors ten times as much as a rare in spread complexity. (Mark
> Rosewater, my apologies if I'm misremembering here!)
>
> The same applies here. When you cast your eye over a program, you're
> going to see certain syntactic elements a lot. Assignment, arithmetic,
> blocks of code (ie indent/dedent), and function calls are all
> extremely common; lambdas, the use of decorators, and exception
> handling are somewhat uncommon; and metaclasses, the writing of
> decorators, and reloading of modules are all quite rare.
>
> The elements that occur frequently should be:
> a) Readable and grokkable;
> b) Easily typed on a regular keyboard - no using ASCII character 126
> to mean negation, tyvm!
> c) Make sense.
>
> Rarer elements (and I'm not talking about xenon and plutonium here)
> are allowed to have long names, obscure syntax, or even be shoved away
> in odd modules (the way module reloading is in Python 3). If 0.1% of
> your code is suddenly twice as large as it used to be, will you
> notice? But if a new syntax adds even 5% to the mindspace requirement
> of basic assignment, your code will majorly suffer.
>
> In summary: Terseness trumps verbosity primarily for common
> operations, and only when doing so does not violate rules a and c
> above.
>
> ChrisA

Good to see there is something we agree upon completely.

Not that I mean to say the question as to how verbose a syntax is
appropriate for collection (un)packing is settled; one could
reasonably argue they find tail::tuple too verbose. But parenthesis
are not a terribly good example to compare to, since they are infact
so much more used they are clearly in another category.

*args and **kwargs are debateable in the appropriateness of their
terseness (but I personally like to err on the side of verbosity), but
extended collection unpacking, as in 'head,*tail=sequence', is quite a
rare construct indeed, and here I very strongly feel a more explicit
syntax is preferrable. That is, as a seasoned python 2 user, I wouldnt
have been willing to gamble on what this does when id come across it
for the first time in python 3. Could as well be a completely new use
of the asterisk. But if collection packing/unpacking would be
presented as a more general construct from the start,
'head,tail::tuple=sequence' would be hard to miss.

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

#18000

On Tue, Dec 27, 2011 at 10:44 AM, Eelco <hoogendoorn.eelco@gmail.com> wrote:
> extended collection unpacking, as in 'head,*tail=sequence', is quite a
> rare construct indeed, and here I very strongly feel a more explicit
> syntax is preferrable.

You may be right, but...

> ... if collection packing/unpacking would be
> presented as a more general construct from the start,
> 'head,tail::tuple=sequence' would be hard to miss.

... it doesn't really justify a _change_. When a language is in its
infancy and the only code written in it is on the designers' own
computers, these sorts of debates can be tipped by relatively small
differences - is it more readable, is it quick enough to type, etc.
But once a language reaches a level of maturity, changes need to
overwhelm the "but it's a change" hurdle - breaking existing code is
majorly dangerous, and keeping two distinct ways of doing something
means you get the worst of both worlds.

We can argue till the cows come home as to which way would be better,
_had Python started with it_. I don't think there's anything like
enough difference to justify the breakage/duplication.

ChrisA

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

#18018

On Dec 27, 1:52 am, Chris Angelico <ros...@gmail.com> wrote:
> On Tue, Dec 27, 2011 at 10:44 AM, Eelco <hoogendoorn.ee...@gmail.com> wrote:
> > extended collection unpacking, as in 'head,*tail=sequence', is quite a
> > rare construct indeed, and here I very strongly feel a more explicit
> > syntax is preferrable.
>
> You may be right, but...
>
> > ... if collection packing/unpacking would be
> > presented as a more general construct from the start,
> > 'head,tail::tuple=sequence' would be hard to miss.
>
> ... it doesn't really justify a _change_. When a language is in its
> infancy and the only code written in it is on the designers' own
> computers, these sorts of debates can be tipped by relatively small
> differences - is it more readable, is it quick enough to type, etc.
> But once a language reaches a level of maturity, changes need to
> overwhelm the "but it's a change" hurdle - breaking existing code is
> majorly dangerous, and keeping two distinct ways of doing something
> means you get the worst of both worlds.
>
> We can argue till the cows come home as to which way would be better,
> _had Python started with it_. I don't think there's anything like
> enough difference to justify the breakage/duplication.

That I agree with; I think it is a questionable idea to introduce this
in a new python 3 version. But I consider it a reasonable change for a
'python 4', or whatever the next major version change will be called.
Writing a code-conversion tool to convert from *args to args::tuple
would be quite easy indeed.

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

#18366

On Dec 27 2011, 8:01 pm, Eelco <hoogendoorn.ee...@gmail.com> wrote:
> But I consider it a reasonable change for a
> 'python 4', or whatever the next major version change will be called.

You do realise there were 8 years between 2 & 3? You might be waiting
for quite some time.

Conversely, you could pitch in behind Rick Johnson's Python 4000 fork,
I sure it's progressing nicely given how long Rick has been talking it
up.

> Writing a code-conversion tool to convert from *args to args::tuple
> would be quite easy indeed.

You might want to ask people maintaining libraries in both 2.x & 3.x
via 2to3 just how well that's working out for them. If the impact of
changes was trivially obvious, the programming landscape would look
very different indeed.

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

#18374

On Jan 2, 8:38 pm, alex23 <wuwe...@gmail.com> wrote:

> Conversely, you could pitch in behind Rick Johnson's Python 4000 fork,
> I sure it's progressing nicely given how long Rick has been talking it
> up.

It's NOT a fork Alex. It IS in fact the next logical step in Python's
future evolution.

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

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

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

csiph-web