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

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

Verbose and flexible args and kwargs syntax

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

Contents

  Verbose and flexible args and kwargs syntax Eelco Hoogendoorn <hoogendoorn.eelco@gmail.com> - 2011-12-12 00:44 +0100
    Re: Verbose and flexible args and kwargs syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-12 01:11 +0000
      Re: Verbose and flexible args and kwargs syntax Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-12-12 21:09 +1300
        Re: Verbose and flexible args and kwargs syntax Terry Reedy <tjreedy@udel.edu> - 2011-12-12 10:36 -0500
        Re: Verbose and flexible args and kwargs syntax Nick Dokos <nicholas.dokos@hp.com> - 2011-12-12 10:55 -0500
        Re: Verbose and flexible args and kwargs syntax Arnaud Delobelle <arnodel@gmail.com> - 2011-12-12 16:15 +0000
        Re: Verbose and flexible args and kwargs syntax Chris Angelico <rosuav@gmail.com> - 2011-12-13 03:16 +1100
        Re: Verbose and flexible args and kwargs syntax Chris Angelico <rosuav@gmail.com> - 2011-12-13 03:19 +1100
      Re: Verbose and flexible args and kwargs syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-12 04:21 -0800
        Re: Verbose and flexible args and kwargs syntax Ian Kelly <ian.g.kelly@gmail.com> - 2011-12-12 11:09 -0700
          Re: Verbose and flexible args and kwargs syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-12 10:17 -0800
            Re: Verbose and flexible args and kwargs syntax Ian Kelly <ian.g.kelly@gmail.com> - 2011-12-12 11:35 -0700
              Re: Verbose and flexible args and kwargs syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-12 10:51 -0800
                Re: Verbose and flexible args and kwargs syntax Ian Kelly <ian.g.kelly@gmail.com> - 2011-12-12 17:34 -0700
                  Re: Verbose and flexible args and kwargs syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-13 00:31 -0800
              Re: Verbose and flexible args and kwargs syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-12 11:05 -0800
                Re: Verbose and flexible args and kwargs syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-12 11:20 -0800
        Re: Verbose and flexible args and kwargs syntax alex23 <wuwei23@gmail.com> - 2011-12-12 15:54 -0800
        Re: Verbose and flexible args and kwargs syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-13 02:43 +0000
          Re: Verbose and flexible args and kwargs syntax Chris Angelico <rosuav@gmail.com> - 2011-12-13 14:08 +1100
          Re: Verbose and flexible args and kwargs syntax Ian Kelly <ian.g.kelly@gmail.com> - 2011-12-12 21:52 -0700
          Re: Verbose and flexible args and kwargs syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-13 01:15 -0800
            Re: Verbose and flexible args and kwargs syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-13 01:50 -0800
              Re: Verbose and flexible args and kwargs syntax Arnaud Delobelle <arnodel@gmail.com> - 2011-12-13 10:15 +0000
                Re: Verbose and flexible args and kwargs syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-13 02:39 -0800
                Re: Verbose and flexible args and kwargs syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-13 02:46 -0800
                  Re: Verbose and flexible args and kwargs syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-13 11:28 +0000
                    Re: Verbose and flexible args and kwargs syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-13 04:19 -0800
            Re: Verbose and flexible args and kwargs syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-13 11:13 +0000
              Re: Verbose and flexible args and kwargs syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-13 04:47 -0800
                Re: Verbose and flexible args and kwargs syntax Chris Angelico <rosuav@gmail.com> - 2011-12-14 00:14 +1100
                  Re: Verbose and flexible args and kwargs syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-13 05:35 -0800
      Re: Verbose and flexible args and kwargs syntax "OKB (not okblacke)" <brenNOSPAMbarn@NObrenSPAMbarn.net> - 2011-12-12 19:45 +0000
    Re: Verbose and flexible args and kwargs syntax Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2011-12-12 12:59 +0200
      Re: Verbose and flexible args and kwargs syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-12 03:22 -0800
        Re: Verbose and flexible args and kwargs syntax Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2011-12-12 13:46 +0200
      Re: Verbose and flexible args and kwargs syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-12 03:18 -0800
      Re: Verbose and flexible args and kwargs syntax Terry Reedy <tjreedy@udel.edu> - 2011-12-12 10:39 -0500
        Re: Verbose and flexible args and kwargs syntax Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2011-12-12 18:52 +0200
          Re: Verbose and flexible args and kwargs syntax Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-12 09:29 -0800
            Re: Verbose and flexible args and kwargs syntax Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2011-12-12 20:09 +0200
            % is not an operator [was Re: Verbose and flexible args and kwargs syntax] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-14 03:18 +0000
              Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax] Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-13 23:49 -0800
                Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax] Arnaud Delobelle <arnodel@gmail.com> - 2011-12-14 11:55 +0000
                  Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax] Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-14 04:33 -0800
                    Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax] Arnaud Delobelle <arnodel@gmail.com> - 2011-12-14 16:13 +0000
                      Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax] Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-14 09:15 -0800
                        Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax] rusi <rustompmody@gmail.com> - 2011-12-14 19:43 -0800
                          Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax] Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-15 01:44 -0800
                            Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax] rusi <rustompmody@gmail.com> - 2011-12-15 02:56 -0800
                              Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax] Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-15 03:37 -0800
              Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax] Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2011-12-14 10:56 +0200
                Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax] Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-14 02:09 -0800
                  Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax] Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2011-12-14 14:22 +0200
                    Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax] Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-14 04:41 -0800
                  Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-14 12:38 +0000
                    Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax] Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-14 05:29 -0800
                      Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax] Chris Angelico <rosuav@gmail.com> - 2011-12-15 00:39 +1100
                      Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax] Ian Kelly <ian.g.kelly@gmail.com> - 2011-12-14 08:45 -0700
                  Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax] Terry Reedy <tjreedy@udel.edu> - 2011-12-14 15:57 -0500
                Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax] rusi <rustompmody@gmail.com> - 2011-12-14 03:47 -0800
                  Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax] Chris Angelico <rosuav@gmail.com> - 2011-12-14 22:53 +1100
                  Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax] Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2011-12-14 15:09 +0200
                Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-14 12:32 +0000
                  Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax] Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2011-12-14 15:21 +0200
                  Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax] Robert Kern <robert.kern@gmail.com> - 2011-12-15 10:47 +0000
                    Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax] Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-15 02:59 -0800
                      Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax] alex23 <wuwei23@gmail.com> - 2011-12-15 18:14 -0800
                        Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax] MRAB <python@mrabarnett.plus.com> - 2011-12-16 02:58 +0000
                          Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax] Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-16 02:36 -0800
                        Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax] Chris Angelico <rosuav@gmail.com> - 2011-12-16 16:01 +1100
                          Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax] alex23 <wuwei23@gmail.com> - 2011-12-15 21:30 -0800
                            Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax] Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-16 02:25 -0800
                              Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax] rusi <rustompmody@gmail.com> - 2011-12-16 09:38 -0800
                                Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax] Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-16 11:40 -0800
                                  Re: % is not an operator [was Re: Verbose and flexible args and   kwargs syntax] Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-12-17 12:49 +1300
                                    Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax] Eelco <hoogendoorn.eelco@gmail.com> - 2011-12-16 16:00 -0800
                                      Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax] Roy Smith <roy@panix.com> - 2011-12-16 19:03 -0500
                                    Re: % is not an operator [was Re: Verbose and flexible args and   kwargs syntax] Grant Edwards <invalid@invalid.invalid> - 2011-12-17 20:02 +0000
                                  Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-17 00:54 +0000
                                    Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax] David Robinow <drobinow@gmail.com> - 2011-12-16 21:11 -0500
                  Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax] Chris Angelico <rosuav@gmail.com> - 2011-12-15 21:58 +1100
                    Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax] rusi <rustompmody@gmail.com> - 2011-12-15 03:04 -0800
                      Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax] Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2011-12-15 14:48 +0200
                      Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax] Terry Reedy <tjreedy@udel.edu> - 2011-12-15 18:15 -0500
              Re: % is not an operator Paul Rudin <paul.nospam@rudin.co.uk> - 2011-12-14 09:43 +0000
          Re: Verbose and flexible args and kwargs syntax Nick Dokos <nicholas.dokos@hp.com> - 2011-12-12 12:58 -0500
            Re: Verbose and flexible args and kwargs syntax Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2011-12-14 11:04 +0200
    Re: Verbose and flexible args and kwargs syntax gene heskett <gheskett@wdtv.com> - 2011-12-12 12:46 -0500
    Re: Verbose and flexible args and kwargs syntax Dave Angel <d@davea.name> - 2011-12-12 13:04 -0500
    Re: Verbose and flexible args and kwargs syntax Nick Dokos <nicholas.dokos@hp.com> - 2011-12-12 13:02 -0500

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

#16993 — Verbose and flexible args and kwargs syntax

>  No more so than any other form of punctuation. Plus and minus + - may be
>  so common that just about everyone knows it, but how about | == @ % and
>  even . (dot)? None of these things will be obvious to newbies who have
>  never programmed before. Oh well.

>  Some things you just have to learn.


Yes, some things you just have to learn. Nonetheless, I strongly prefer 
explicit logical operators over |, would much rather have 'equals' 
instead of ==, which is stylistic in line with 'is' and explicitly 
distinguishes between equality and identity comparisons. As for %; it is 
entirely unclear to me why that obscure operation ever got its own 
one-character symbol. Ill take 'mod', or even better, 'modulus' any day 
of the week.

The dot is clearly quantitatively in another realm here. 90% of typical 
python code is attribute accesses. The dot is entirely unambigious and 
cannot be mistaken for anything else. It reads like a book.

>  It's a judgement call as to where a language divides "cryptic punctuation
>  line noise" and "useful short operators", and in my opinion * and ** tuple
>  and dict unpacking fall strongly on the "useful short operators" side.
>  Your opinion may differ, but luckily for me, the BDFL agrees with me :)

I also agree that it is a value judgement as to which constructs get 
their own cryptic symbols and which do not, but the are some reasonable 
guidelines we should be able to agree upon. Obscure operations should 
not reserve any of the few available characters. Furthermore, the 
language should not just be formally consistent, but also easy to grasp 
at a glance, without deciphering subtle semantics of a blurb of weird 
characters. (some programming languages obviously disagree, but python, 
as far as I am allowed to speak for it, does not). And most importantly, 
if you cant come up with a terse syntax that does everything you want to 
do, the terse syntax should at best be an alternative to the verbose one.


>  It is also misleading because args are not collected into a list, but
>  into a tuple.

In case you wanted a tuple youd write tuple(args), obviously. Exactly that added flexibility is half of my case in favor. Why shouldnt it be a list when I want it to?



>  Worse, it suggests that one should be able to generalise to
>  something like this:

>  def func(parg, str(args), int(kwargs), my_func(more_args)):

>  which is incoherent.

Sorry, but I dont get this point at all. Does ** suggests one should be 
able to generalize to ***? The rules are the rules.



The real questions, in my mind, are:

1) How useful is this added flexibility? Not insanely, but I can see it 
making a lot of code significantly more clean.

And:

2) How fundamental is collection packing/unpacking? One can easily argue 
that it is indeed quite fundamental and therefore deserves its own terse 
symbols, I feel. However, if more flexibility is indeed deemed 
desirable, such terse syntax quickly gives way to a more verbose one. 
Can you come up with some terse symbols that will be able to express all 
of the below and dont make you wish you hadnt rather typed out the names?

head, tuple(tail) = iterable
head, list(tail) = iterable
head, str(tail) = somestring
head, generator(tail) = mygenerator

And so on.

If not, one has to admit that functionality is being sacrificed on the 
alter of terseness, which seems like a raw deal to me.

[toc] | [next] | [standalone]

#16997

On Mon, 12 Dec 2011 00:44:38 +0100, Eelco Hoogendoorn wrote:

>>  No more so than any other form of punctuation. Plus and minus + - may
>>  be so common that just about everyone knows it, but how about | == @ %
>>  and even . (dot)? None of these things will be obvious to newbies who
>>  have never programmed before. Oh well.
> 
>>  Some things you just have to learn.
> 
> 
> Yes, some things you just have to learn. Nonetheless, I strongly prefer
> explicit logical operators over |, would much rather have 'equals'
> instead of ==, which is stylistic in line with 'is' and explicitly
> distinguishes between equality and identity comparisons.

No more, or less, explicit than the difference between "==" and "is". 


> As for %; it is
> entirely unclear to me why that obscure operation ever got its own
> one-character symbol. Ill take 'mod', or even better, 'modulus' any day
> of the week.

Modulo is hardly an obscure operation. "What's the remainder...?" is a 
simple question that people learn about in primary school. 

And you can blame C for the use of % instead of mod or modulo.


> The dot is clearly quantitatively in another realm here. 90% of typical
> python code is attribute accesses.

I can't imagine what sort of Python code you have seen that you consider 
90% attribute access "typical". I've just run the Python tokenizer over 
my startup.py file, and I get these results:

{'COMMENT': 24, 'DEDENT': 29, 'NL': 46, 'NAME': 256, "':'": 30, 
'NEWLINE': 83, "'-'": 1, 'NUMBER': 1, "'['": 1, "','": 17, "')'": 37, 
"'('": 37, "'%'": 2, "'.'": 48, "'=='": 1, "'*'": 1, 'INDENT': 29, "']'": 
1, "'='": 28, 'ENDMARKER': 1, 'STRING': 19}

That gives attribute access being a little less than 7% of the source 
code. For the decimal module, the figure is a little less than 5%.


> The dot is entirely unambigious and
> cannot be mistaken for anything else. It reads like a book.

The dot can be easily mistaken for a comma, or for a bit of grit on the 
monitor, especially at smaller type sizes, or for those with poor 
eyesight.


[...]
>>  It is also misleading because args are not collected into a list, but
>>  into a tuple.
> 
> In case you wanted a tuple youd write tuple(args), obviously. Exactly
> that added flexibility is half of my case in favor. Why shouldnt it be a
> list when I want it to?

What sort of list? A built-in list, or whatever sort of object you get 
when you call the thing currently bound to the name "list"?

If you can supply any function at all, what happens if I write this:

def func(parg, dict(foo), list(bar)): ...

How about this?

def func(parg, myfunc(x)): ...

What is x now? Should Python try to accumulate arguments by position, or 
by keyword, or try both and hope one will succeed? Which order should it 
try first?

I believe that your proposal leads to an over-generalisation "call 
arbitrary functions when handling parameter lists". I don't believe you 
need this added complication. If you want to your var args as a list, 
call list(args) inside your function.


>>  Worse, it suggests that one should be able to generalise to something
>>  like this:
> 
>>  def func(parg, str(args), int(kwargs), my_func(more_args)):
> 
>>  which is incoherent.
> 
> Sorry, but I dont get this point at all. Does ** suggests one should be
> able to generalize to ***? The rules are the rules.

You have missed that the generalization is not just to multiple "chunks" 
of arguments, but also to arbitrary functions. I thought that both ideas 
were equally incoherent, but ironically you suggest about that you should 
be able to call arbitrary functions: tuple, list, attrdict. What else? 
str? int? 


> The real questions, in my mind, are:
> 
> 1) How useful is this added flexibility? Not insanely, but I can see it
> making a lot of code significantly more clean.

I don't. I see it making a small amount of code more verbose and less 
clean.


> And:
> 
> 2) How fundamental is collection packing/unpacking? One can easily argue
> that it is indeed quite fundamental and therefore deserves its own terse
> symbols, I feel.

In Python, tuple unpacking and packing (actually applies to any 
collection, not just tuples) is *very* fundamental. That's why we can do 
things like this:

a, b, c = my_list
x, y = y, x

> However, if more flexibility is indeed deemed
> desirable, such terse syntax quickly gives way to a more verbose one.
> Can you come up with some terse symbols that will be able to express all
> of the below and dont make you wish you hadnt rather typed out the
> names?
> 
> head, tuple(tail) = iterable

In Python 3, that is spelled:

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


> head, list(tail) = iterable

head, *tail = iterable


> head, str(tail) = somestring

This is ambiguous, I'm not sure what exactly you expect to get as the 
string. It could arguable be any of:

tail = ''.join(map(repr, tail))
tail = ''.join(map(str, tail))
tail = str(tail)

or even

head, tail = somestring[0], somestring[1:]


> head, generator(tail) = mygenerator

And this is most easily spelled:

head, tail = next(mygenerator), mygenerator



-- 
Steven

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

#17020

Steven D'Aprano wrote:

> Modulo is hardly an obscure operation. "What's the remainder...?" is a 
> simple question that people learn about in primary school.

Well, sort of. The way I remember it, the remainder was just
something that fell out as a side effect of division -- the
annoying bit left over that you didn't know what to do with.
We weren't taught to think of "finding the remainder" as
a distinct operation that's useful in its own right. Once
we were taught to do proper division with decimal points
and everything, the concept of a remainder seemed to get
discarded and was never mentioned again.

A couple of years later we were briefly introduced to the
concept of modulo arithmetic, but as far as I remember, the
connection with division and remainders wasn't pointed out.
Also, it was presented in a very abstract way, and I couldn't
see any practical application for it at the time. (At that
age, it hadn't occurred to me that some of the stuff we
were being shown might be just pure mathematics for its own
sake, and I was often thinking to myself, "Why am I being
taught this?")

It wasn't until much later when I got into programming that
I began to see all the connections and applications. For
people who don't become programmers, I suspect they never
have much use for remainders in everyday life.

Now, in a desperate attempt to stop rambling and get back
on topic...

> Eelco Hoogendoorn wrote:
>>The dot is clearly quantitatively in another realm here.

Also it has almost unchallenged supremacy as the attribute
access operator in just about every language having some
form of struct concept, going back to around Algol 68.
Spelling of the mod operator is much more variable.

> {'COMMENT': 24, 'DEDENT': 29, 'NL': 46, 'NAME': 256, "':'": 30, 
> 'NEWLINE': 83, "'-'": 1, 'NUMBER': 1, "'['": 1, "','": 17, "')'": 37, 
> "'('": 37, "'%'": 2, "'.'": 48, "'=='": 1, "'*'": 1, 'INDENT': 29, "']'": 
> 1, "'='": 28, 'ENDMARKER': 1, 'STRING': 19}
> 
> That gives attribute access being a little less than 7% of the source 
> code.

However, it's clearly the most commonly used *operator* by
a large margin.

> The dot can be easily mistaken for a comma,

Not in my code, because I always put a space after a comma,
and never after an attribute-access dot. (And if you can't
tell whether there's a space there or not, you need a
bigger font or better glasses. :-)

Also, dots sit nicely under my little finger where they're
easy to type. I like dots. Dots are a great goodness.

-- 
Greg

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

#17047

On 12/12/2011 3:09 AM, Gregory Ewing wrote:

> people who don't become programmers, I suspect they never
> have much use for remainders in everyday life.

Huh? Funny you should say 'everyday'. It is now 10 o'clock. In 20 hours, 
it will be (10+20) % 12 == 6 o'clock. It is now day 1 of the week. In 9 
days it will be day (1+9) % 7 == 3 of the week. Mental calculations are 
helped by the fact that (a+b) % c == a%c + b%c, so that would actually 
be 1+2==3. Timekeeping is mostly remaindering, slightly obscured by 
using 12 instead of 0.

-- 
Terry Jan Reedy

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

#17053

Terry Reedy <tjreedy@udel.edu> wrote:


> calculations are helped by the fact that (a+b) % c == a%c + b%c, so

As long as we understand that == here does not mean "equal", only
"congruent modulo c", e.g try a = 13, b = 12, c = 7.

Nick

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

#17056

On 12 December 2011 15:36, Terry Reedy <tjreedy@udel.edu> wrote:
> Huh? Funny you should say 'everyday'. It is now 10 o'clock. In 20 hours, it
> will be (10+20) % 12 == 6 o'clock. It is now day 1 of the week. In 9 days it
> will be day (1+9) % 7 == 3 of the week. Mental calculations are helped by
> the fact that (a+b) % c == a%c + b%c

You mean (a + b) % c == (a%c + b%c) % c

:)

-- 
Arnaud

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

#17057

On Tue, Dec 13, 2011 at 2:55 AM, Nick Dokos <nicholas.dokos@hp.com> wrote:
> Terry Reedy <tjreedy@udel.edu> wrote:
>> calculations are helped by the fact that (a+b) % c == a%c + b%c, so
>
> As long as we understand that == here does not mean "equal", only
> "congruent modulo c", e.g try a = 13, b = 12, c = 7.

This is the basis of the grade-school "casting out nines" method of
checking arithmetic. Set c=9 and you can calculate N%c fairly readily
(digit sum - I'm assuming here that the arithmetic is being done in
decimal); the sum of the remainders should equal the remainder of the
sum, but there's the inherent assumption that if the remainders sum to
something greater than nine, you digit-sum it to get the true
remainder.

(Technically the sum of the digits of a base-10 number is not the same
as that number mod 9, but if you accept that 0 == 9, it works fine.)

ChrisA

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

#17058

On Tue, Dec 13, 2011 at 3:15 AM, Arnaud Delobelle <arnodel@gmail.com> wrote:
>
> You mean (a + b) % c == (a%c + b%c) % c
>
> :)

It's just integer wraparound. Modulo 9 is the same as "render this
number in base 9 and take the last digit" (and printing a number in
base 9 would normally be done with mod 9 division), and most people
can wrap their heads around the way an odometer wraps around.

ChrisA

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

#17035

> No more, or less, explicit than the difference between "==" and "is".

== may be taken to mean identity comparison; 'equals' can only mean
one
thing. Of course 'formally' these symbols are well defined, but so is
brainf*ck

>  Modulo is hardly an obscure operation. "What's the remainder...?" is a
>  simple question that people learn about in primary school.


So is 'how much wood would a woodchucker chuck if a woodchucker could
chuck wood?'. But how often does that concept turn up in your code?

> And you can blame C for the use of % instead of mod or modulo.

I didnt know one of Python's design goals was backwards compatibility
with C.

>  I can't imagine what sort of Python code you have seen that you consider
>  90% attribute access "typical". I've just run the Python tokenizer over
>  my startup.py file, and I get these results:

Yes, that was a hyperbole; but quite an often used construct, is it
not?

>  If you can supply any function at all, what happens if I write this:


You cannot; only constructors modelling a sequence or a dict, and
only
in that order. Is that rule clear enough?

> I believe that your proposal leads to an over-generalisation "call
> arbitrary functions when handling parameter lists".

I hope the above clears that up. It is as much about calling
functions
as ** is about raising kwargs to the power of.

> I don't believe you
> need this added complication. If you want to your var args as a list,
> call list(args) inside your function.

We dont strictly 'need' any language construct. Real men use
assembler,
right?


>  >  head, tuple(tail) = iterable
>  In Python 3, that is spelled:
>  head, *tail = iterable
>  tail = tuple(tail)

Yes, I know. How is that not a lot more verbose and worse than what I
have proposed in all possible ways?

> head, tail = somestring[0], somestring[1:]

Well yes, splendid; we can do that with lists too since the dawn of
Python. What you are saying here in effect is that you think the
head/tail syntax is superfluous; that youd rather see it eliminated
than
generalized.

> head, tail = next(mygenerator), mygenerator

Which again of course works, but is yet again of entirely different
form
than any of the above solutions, while conceptually doing the same
thing. Certainly, there is room for improved elegance here?

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

#17069

On Mon, Dec 12, 2011 at 5:21 AM, Eelco <hoogendoorn.eelco@gmail.com> wrote:
> You cannot; only constructors modelling a sequence or a dict, and
> only
> in that order. Is that rule clear enough?

The dict constructor can receive either a sequence or a mapping, so if
I write this:

        def func(a, b, dict(c)):

what will I get?  Probably I would want the equivalent of:

        def func(a, b, **c):

but you seem to be saying that I would actually get the equivalent of this:

        def func(a, b, *c):
            c = dict(c)

Cheers,
Ian

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

#17073

On Dec 12, 7:09 pm, Ian Kelly <ian.g.ke...@gmail.com> wrote:
> On Mon, Dec 12, 2011 at 5:21 AM, Eelco <hoogendoorn.ee...@gmail.com> wrote:
> > You cannot; only constructors modelling a sequence or a dict, and
> > only
> > in that order. Is that rule clear enough?
>
> The dict constructor can receive either a sequence or a mapping, so if
> I write this:
>
>         def func(a, b, dict(c)):
>
> what will I get?  Probably I would want the equivalent of:
>
>         def func(a, b, **c):
>
> but you seem to be saying that I would actually get the equivalent of this:
>
>         def func(a, b, *c):
>             c = dict(c)
>
> Cheers,
> Ian

Im not sure if I was clear on that, but I dont care what the
constructors accept; I meant to overload on the concept the underlying
type models. Dicts model a mapping, lists/tuples model a sequence. MI
deriving from both these models is illegal anyway, so one can
unambigiously overload on that trait.

The syntax only superficially resembles 'call the dict constructor
with the object passed into kwargs'. What its supposed to mean is
exactly the same as **kwargs, but with added flexibility.

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

#17074

On Mon, Dec 12, 2011 at 11:17 AM, Eelco <hoogendoorn.eelco@gmail.com> wrote:
> Im not sure if I was clear on that, but I dont care what the
> constructors accept; I meant to overload on the concept the underlying
> type models. Dicts model a mapping, lists/tuples model a sequence. MI
> deriving from both these models is illegal anyway, so one can
> unambigiously overload on that trait.

False.

>>> from collections import *
>>> class Foo(Sequence, Mapping):
...     def __init__(self, items):
...         self._items = items
...     def __getitem__(self, item):
...         return self._items[item]
...     def __len__(self):
...         return len(self._items)
...
>>> foo1 = Foo(range(5, 10))
>>> foo2 = Foo({'one': 1, 'two': 2})
>>> foo1[3]
8
>>> foo2['one']
1

Or are you saying that only classes specifically derived from list,
tuple, or dict should be considered, and custom containers that are
not derived from any of those but implement the correct protocols
should be excluded?  If so, that sounds less than ideal.

Cheers,
Ian

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

#17075

> False.

I stand corrected.

> Or are you saying that only classes specifically derived from list,
> tuple, or dict should be considered, and custom containers that are
> not derived from any of those but implement the correct protocols
> should be excluded?  If so, that sounds less than ideal.

That might be a desirable constraint from an implementational/
performance aspect anyway, but I agree, less than ideal.

Either way, its not hard to add some detail to the semantics to allow
all this. Even this function definition:

def func(Foo(args), Foo(kwargs))

...could even be defined unambigiously by overloading first on base
type, and if that does not uniquely determine the args and kwargs,
fall back on positionality, so that:

def func(Foo(args), dict(kwargs))
def func(list(args), Foo(kwargs))

would be uniquely defined as well.

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

#17092

On Mon, Dec 12, 2011 at 11:51 AM, Eelco <hoogendoorn.eelco@gmail.com> wrote:
> Either way, its not hard to add some detail to the semantics to allow
> all this. Even this function definition:
>
> def func(Foo(args), Foo(kwargs))
>
> ...could even be defined unambigiously by overloading first on base
> type, and if that does not uniquely determine the args and kwargs,
> fall back on positionality, so that:
>
> def func(Foo(args), dict(kwargs))
> def func(list(args), Foo(kwargs))
>
> would be uniquely defined as well.

That solves some of the problems, but if I just have:

        def func(SequenceOrMappingType(args)):

That's going to unpack positionally.  If I want it to unpack keywords
instead, how would I change the definition to indicate that?

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

#17107

On Dec 13, 1:34 am, Ian Kelly <ian.g.ke...@gmail.com> wrote:
> On Mon, Dec 12, 2011 at 11:51 AM, Eelco <hoogendoorn.ee...@gmail.com> wrote:
> > Either way, its not hard to add some detail to the semantics to allow
> > all this. Even this function definition:
>
> > def func(Foo(args), Foo(kwargs))
>
> > ...could even be defined unambigiously by overloading first on base
> > type, and if that does not uniquely determine the args and kwargs,
> > fall back on positionality, so that:
>
> > def func(Foo(args), dict(kwargs))
> > def func(list(args), Foo(kwargs))
>
> > would be uniquely defined as well.
>
> That solves some of the problems, but if I just have:
>
>         def func(SequenceOrMappingType(args)):
>
> That's going to unpack positionally.  If I want it to unpack keywords
> instead, how would I change the definition to indicate that?

That should raise an ambiguity error. But honestly, how often have you
worked with SequenceOrMappingType's? I think this is a rather
palatable constraint.

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

#17076

To get back on topic a little bit, lets get back to the syntax of all
this: I think we all agree that recycling the function call syntax is
less than ideal, since while it works in special contexts like a
function signature, its symmetric counterpart inside a function call
already has the meaning of a function call.

In general, we face the problem of specifying metadata about a
variable, or a limited form of type constraint.

What we want is similar to function annotations in python 3; in line
with that, we could have more general variable annotations. With an
important conceptual distinction; function annotations are meaningless
to python, but the annotations I have in mind should modify semantics
directly. However, its still conceptually close enough that we might
want to use the colon syntax here too. To distinguish it from function
annotations, we could use a double colon (double colon is an
annotation with non-void semantics; quite a simple rule); or to
maintain an historic link with the existing packing/unpacking syntax,
we could look at an augmented form of the asteriks notation.

For instance:

def func(list*args, dict*kwargs) <- list-of-args, dict-of-kwargs
def func(args::list, kwargs::dict) <- I like the readability of this
one even better; args-list and kwargs-dict

And:

head, deque*tail = somedeque
head, tail::deque = somedeque

Or some variants thereof

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

#17077

On Dec 12, 8:05 pm, Eelco <hoogendoorn.ee...@gmail.com> wrote:
> To get back on topic a little bit, lets get back to the syntax of all
> this: I think we all agree that recycling the function call syntax is
> less than ideal, since while it works in special contexts like a
> function signature, its symmetric counterpart inside a function call
> already has the meaning of a function call.
>
> In general, we face the problem of specifying metadata about a
> variable, or a limited form of type constraint.
>
> What we want is similar to function annotations in python 3; in line
> with that, we could have more general variable annotations. With an
> important conceptual distinction; function annotations are meaningless
> to python, but the annotations I have in mind should modify semantics
> directly. However, its still conceptually close enough that we might
> want to use the colon syntax here too. To distinguish it from function
> annotations, we could use a double colon (double colon is an
> annotation with non-void semantics; quite a simple rule); or to
> maintain an historic link with the existing packing/unpacking syntax,
> we could look at an augmented form of the asteriks notation.
>
> For instance:
>
> def func(list*args, dict*kwargs) <- list-of-args, dict-of-kwargs
> def func(args::list, kwargs::dict) <- I like the readability of this
> one even better; args-list and kwargs-dict
>
> And:
>
> head, deque*tail = somedeque
> head, tail::deque = somedeque
>
> Or some variants thereof

As for calling functions; calling a function with the content of a
collection type rather than the collection as an object itself is a
rather weird special case operation I suppose, but we can cover it
with the same syntax:

def func(args::tuple, kwargs::dict):
    funccall(args::, kwargs::) <- void type constraint means
unpacking, for symmetry with args/kwargs aggregation
    funccall(::args, ::kwargs) <- I like this better, to emphasize it
being 'the other side' of the same coin, and quite close to ** syntax

Sequence and Mapping unpacking dont need their own symbols, if things
are done like this, since in the function declaration the meaning is
clear from the type of the annotations used, plus their position, and
in the call the meaning is clear from the type of the object
undergoing to unpacking operation.

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

#17088

On Dec 12, 10:21 pm, Eelco <hoogendoorn.ee...@gmail.com> wrote:
> >  Modulo is hardly an obscure operation. "What's the remainder...?" is a
> >  simple question that people learn about in primary school.
>
> So is 'how much wood would a woodchucker chuck if a woodchucker could
> chuck wood?'. But how often does that concept turn up in your code?

That comment right there? That's the moment every serious coder
stopped paying attention to a single word you say.

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

#17102

On Mon, 12 Dec 2011 04:21:15 -0800, Eelco wrote:

>> No more, or less, explicit than the difference between "==" and "is".
> 
> == may be taken to mean identity comparison; 'equals' can only mean one
> thing.

Nonsense. "Equals" can be taken to mean anything the language designer 
chooses, same as "==". There is no language police that enforces The One 
True Meaning Of Equals. In fact, there is no one true meaning of equals. 
Even my tiny Pocket Oxford dictionary lists five definitions.

It is ironic that the example you give, that of identity, is the standard 
definition of equals in mathematics. 2*2 = 4 does not merely say that 
"there is a thing, 2*2, which has the same value as a different thing, 
4", but that both sides are the same thing. Two times two *is* four. All 
numbers are, in some sense, singletons and equality implies identity.

A language designer might choose to define equals as an identity test, or 
as a looser "values are the same" test where the value of an object or 
variable is context dependent, *regardless* of how they are spelled: = == 
=== "is" "equals" or even "flibbertigibbet" if they wanted to be 
whimsical. The design might allow types to define their own sense of 
equality.

Triangle.equals(other_triangle) might be defined to treat any two 
congruent triangles as equal; set equality could be defined as an 
isomorphism relation; string equality could be defined as case-
insensitive, or to ignore leading and trailing whitespace. Regardless of 
whether you or I *would* make those choices, we *could* make those 
choices regardless of how our language spells the equality test.


> Of course 'formally' these symbols are well defined, but so is
> brainf*ck

I don't understand your point here.



>>  Modulo is hardly an obscure operation. "What's the remainder...?" is a
>>  simple question that people learn about in primary school.
> 
> 
> So is 'how much wood would a woodchucker chuck if a woodchucker could
> chuck wood?'. But how often does that concept turn up in your code?

You didn't make a statement about how often modulo turns up in code 
(which is actually quite frequently, and possibly more frequently than 
regular division), but about the obscurity of the operation. Taking the 
remainder is not an obscure operation. The names "modulo" and "modulus" 
may be obscure to those who haven't done a lot of mathematics, but the 
concept of remainder is not. "How many pieces are left over after 
dividing into equal portions" is something which even small children get.


>> And you can blame C for the use of % instead of mod or modulo.
> 
> I didnt know one of Python's design goals was backwards compatibility
> with C.

Don't be silly. You know full well Python is not backwards compatible 
with C, even if they do share some syntactical features.

C is merely one of many languages which have influenced Python, as are 
Haskell, ABC, Pascal, Algol 68, Perl (mostly in the sense of "what not to 
do" <wink>), Lisp, and probably many others. It merely happens that C's 
use of the notation % for the remainder operation likely influenced 
Python's choice of the same notation.

I note that the *semantics* of the operation differs in the two 
languages, as I understand that the behaviour of % with negative 
arguments is left undefined by the C standard, while Python does specify 
the behaviour.


>>  I can't imagine what sort of Python code you have seen that you
>>  consider 90% attribute access "typical". I've just run the Python
>>  tokenizer over my startup.py file, and I get these results:
> 
> Yes, that was a hyperbole; but quite an often used construct, is it not?

It's hard, but not quite impossible, to write useful Python code without 
it, so yes.

 
>>  If you can supply any function at all, what happens if I write this:
> 
> 
> You cannot; only constructors modelling a sequence or a dict, and only
> in that order. Is that rule clear enough?

But why limit yourself to those restrictive rules?

If I want to collect a sequence of arguments into a string, why shouldn't 
I be allowed to write this?

    def func(parg, str(args)): ...

If I want to sum a collection of arguments, why not write this?

    def func(pargs, sum(args)): ...

Isn't that better than this?

    def func(pargs, *args):
        args = sum(args)
        ...


But no. I don't mean those examples to be taken seriously: when you 
answer to your own satisfaction why they are bad ideas, you may be closer 
to understanding why I believe your idea is also a bad idea.



>> I believe that your proposal leads to an over-generalisation "call
>> arbitrary functions when handling parameter lists".
> 
> I hope the above clears that up. It is as much about calling functions
> as ** is about raising kwargs to the power of.

I don't understand this comment. Nobody has suggested that ** in function 
parameter lists is the exponentiation operator.

As for "calling functions", how else do you expect to generate a type if 
you don't call the type constructor? One of your early examples was 
something like:

def func(parg, attrdict(kwargs)): ...

If you expect kwargs to be an attrdict, which is not a built-in, 
presumably you will have needed to have defined attrdict as a type or 
function, and this type or function will get called at run time to 
collect the kwargs. That is all.

 
>> I don't believe you
>> need this added complication. If you want to your var args as a list,
>> call list(args) inside your function.
> 
> We dont strictly 'need' any language construct. Real men use assembler,
> right?

"We're not using assembly" is not a reason to add a feature to a 
language. Every feature adds cost to the language:

* harder to implement;
* harder to maintainer;
* larger code base;
* more documentation to be written;
* more tests to be written;
* more for users to learn

etc.


>>  >  head, tuple(tail) = iterable
>>  In Python 3, that is spelled:
>>  head, *tail = iterable
>>  tail = tuple(tail)
> 
> Yes, I know. How is that not a lot more verbose and worse than what I
> have proposed in all possible ways?

That *specific* syntax, outside of function declarations, is something 
I've often thought might be useful. But if I were to argue its case, I 
would allow arbitrary functions, and treat it as syntactic sugar for:

head, *tail = iterable
tail = func(tail)  # or possibly func(*tail)

But that's pie-in-the-sky musing. I certainly wouldn't put it in function 
parameter lists. Param lists should be declarations, not code. Apart from 
the most limited collation of args, code belongs inside the body of the 
function, not the param list:

def foo(a, 2*b+1, c):  # double the second arg and add 1


>> head, tail = somestring[0], somestring[1:]
> 
> Well yes, splendid; we can do that with lists too since the dawn of
> Python. What you are saying here in effect is that you think the
> head/tail syntax is superfluous; that youd rather see it eliminated than
> generalized.

No. 

It is not "head/tail" syntax, but sequence unpacking, and it has been 
nicely generalised to allow things like this in Python 3:

a, b, c, d, *lump, x, y z = any_iterable

any_iterable isn't limited to a list, str, or other object which supports 
slicing. It can be any object supporting the iteration protocol.

What I'm saying is that there is no need to OVER-generalise this to 
specify the type of *lump within the packing operation. If you want lump 
to be something other that Python's choice, perform the conversion 
yourself.


-- 
Steven

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

#17103

On Tue, Dec 13, 2011 at 1:43 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> It merely happens that C's
> use of the notation % for the remainder operation likely influenced
> Python's choice of the same notation.

Considering that Python also had the notion that "integer divided by
integer yields integer" until Py3, I would say it's extremely likely
that most of Python's division facilities were modelled off C. That's
not a bad thing; gives you a set of operations that a large number of
people will grok, and only a small number of oddities.

> I note that the *semantics* of the operation differs in the two
> languages, as I understand that the behaviour of % with negative
> arguments is left undefined by the C standard, while Python does specify
> the behaviour.

... and there's the proof that "modelled off" does not mean "slavishly
follows". This lack of definition is a weakness in C.

> def foo(a, 2*b+1, c):  # double the second arg and add 1

No, that should subtract 1 from the second arg and halve it. The
expression you give there has to match the value from the parameter
list.

This syntax would be a huge boon to Python. Imagine how much easier
this could make things:

def foo(sum(x)):
    return x

print(foo(120)) # will print a list of numbers that sum to 120


ChrisA

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

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

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

csiph-web