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

#17104

On Mon, Dec 12, 2011 at 7:43 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> 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)): ...

Obviously, because the correct syntax would be:

def func(parg, ''.join(args)): ...

:-P

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

#17110

On Dec 13, 3:43 am, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> 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.

We are not talking mathemathics, we are talking programming languages.
Identity versus value equality is a well established concept within
its jargon. Within this context, 'equals' and 'is' have clearly
defined meanings. Indeed within broader use, including everyday
language, the distinction is more subtle and therefore less useful,
but obeying a linguistic rule that holds within computer science is
better than making something up just for python, even though its not
the yet better rule that any five year old might grasp.

> > Of course 'formally' these symbols are well defined, but so is
> > brainf*ck
>
> I don't understand your point here.

Hence the above.

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

So 'frequency of use' is no valid interpretation of 'obscurity'? Im
not a native speaker, but im pretty sure it is.

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

Of course I was being silly; I know this use is following a historical
precedent; but id rather see it rectified in the previous version of
python rather than the next. My sillyness was prompted by the
percieved pointlessness of your remark. Of course python is not trying
to be backwards compatible with C; so why bring it up then?

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

They are bad ideas because they truely do not lead to the execution of
different code, but are merely a reordering, mixing statements in with
a function declaration. I am proposing no such thing; again, the
type(arg) notation I have dropped, and never was meant to have
anything to do with function calling; it is a way of supplying an
optional type constraint, so in analogy with function annotations, I
changed that to arg::type. Again, this has nothing to do with calling
functions on arguments.

First off, type constraints must have some use; all those languages
cant be wrong. Ofcourse, no type constraints also can not be wrong;
see all those other languages. And I obviously dont mean to make type
constraits mandatory in python, all im saying is that optionally
allowing them can open some doors in the right places. The * and **
syntax are also in effect type constraints, saying 'this is a dict to
collect the remaining kwargs in', but in a rather cryptic and
needlessly ungeneral method.

#define a function with args-list and kwargs-attrdict
def func(args::list, kwargs::attrdict)
#unpack the sequence args into positional arguments, and the mapping
kwargs into keyword arguments
func(::args, ::kwargs)

So now that I have explained what my idea actually is, perhaps youd
like to explain again why it is 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.

No more or less than I suggested this is about calling functions on
input parameters. The syntax might be superficially similar, but thats
all.

> 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 would like attrdict to be a builtin, and as long as it isnt, that
specific example probably wouldnt work. But all I wnat python to do is
whatever it is doing to build a dict, but then for another type
instead. Hence, a typeconstraint.

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

I agree that this is a bad idea; see the above.

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

Oh, so your primary objection is a semantic nitpick, and the latter is
an OVERgeneralization? Why not restrict unpacking only to lists as
RHS, and convert all your iterables to lists first? Who needs this
overgeneralization of allowing any sequence type to be unpacked,
right?

To answer that question: for the same reasons. The conversion is
wasteful; allowing python to do the right thing based on a
typeconstraint is not. Plus, it is less code, and more readable code;
the only rule you have to learn is quite general, which is that :: is
a type constraint annotation; no need to remember specifics, like
'unpacking always returns lists for some arbitrary reason'.

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

#17114

> To answer that question: for the same reasons. The conversion is
> wasteful; allowing python to do the right thing based on a
> typeconstraint is not. Plus, it is less code, and more readable code;
> the only rule you have to learn is quite general, which is that :: is
> a type constraint annotation; no need to remember specifics, like
> 'unpacking always returns lists for some arbitrary reason'.

Oh my bad; actually, that should be:

'collecting the remainder of an unpacked iterable using * will always
yield a list. That is, unless the construct appears inside a function
definition; then somehow a tuple is always the right choice'

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

#17117

On 13 December 2011 09:50, Eelco <hoogendoorn.eelco@gmail.com> wrote:
>> To answer that question: for the same reasons. The conversion is
>> wasteful; allowing python to do the right thing based on a
>> typeconstraint is not. Plus, it is less code, and more readable code;
>> the only rule you have to learn is quite general, which is that :: is
>> a type constraint annotation; no need to remember specifics, like
>> 'unpacking always returns lists for some arbitrary reason'.
>
> Oh my bad; actually, that should be:
>
> 'collecting the remainder of an unpacked iterable using * will always
> yield a list. That is, unless the construct appears inside a function
> definition; then somehow a tuple is always the right choice'

When you quote somebody (even yourself), it would be helpful if you
attributed your quote.

-- 
Arnaud

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

#17118

On 13 dec, 11:15, Arnaud Delobelle <arno...@gmail.com> wrote:
> On 13 December 2011 09:50, Eelco <hoogendoorn.ee...@gmail.com> wrote:
>
> >> To answer that question: for the same reasons. The conversion is
> >> wasteful; allowing python to do the right thing based on a
> >> typeconstraint is not. Plus, it is less code, and more readable code;
> >> the only rule you have to learn is quite general, which is that :: is
> >> a type constraint annotation; no need to remember specifics, like
> >> 'unpacking always returns lists for some arbitrary reason'.
>
> > Oh my bad; actually, that should be:
>
> > 'collecting the remainder of an unpacked iterable using * will always
> > yield a list. That is, unless the construct appears inside a function
> > definition; then somehow a tuple is always the right choice'
>
> When you quote somebody (even yourself), it would be helpful if you
> attributed your quote.
>
> --
> Arnaud

Ah yes; im more used to proper forums, still getting used to these
mailing-list things. But point taken.

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

#17119

With all this being said, I must say that the notion of indtroducing
type constraints into Python is quite a radical one*, and one that
should not be taken lightly, so I understand the general conservative
vibe the notion is getting. It probably has implications beyond just
collection types, and if youd introduce such a feature, you would like
to introduce it only once, and correctly the first time around.

Ill probably start a new thread soon, recapping the accumulated
insight, and capping all the OT threads that have spawned.

*even though the asteriks syntax is infact a limited form of exactly
that

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

#17125

On Tue, 13 Dec 2011 02:46:13 -0800, Eelco wrote:

> With all this being said, I must say that the notion of indtroducing
> type constraints into Python is quite a radical one*, 

Not that radical. Here's the creator of Python musing about adding 
optional type checks to Python:

http://www.artima.com/weblogs/viewpost.jsp?thread=85551
http://www.artima.com/weblogs/viewpost.jsp?thread=86641
http://www.artima.com/weblogs/viewpost.jsp?thread=87182


[...]
> *even though the asteriks syntax is infact a limited form of exactly
> that

It absolutely is not. def f(*args, **kwargs) constructs a tuple and a 
dict, it does not type-check that the function is passed a tuple and a 
dict as arguments. These are completely different things.


-- 
Steven

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

#17128

On 13 dec, 12:28, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> On Tue, 13 Dec 2011 02:46:13 -0800, Eelco wrote:
> > With all this being said, I must say that the notion of indtroducing
> > type constraints into Python is quite a radical one*,
>
> Not that radical. Here's the creator of Python musing about adding
> optional type checks to Python:
>
> http://www.artima.com/weblogs/viewpost.jsp?thread=85551http://www.artima.com/weblogs/viewpost.jsp?thread=86641http://www.artima.com/weblogs/viewpost.jsp?thread=87182

Good find; but still radical enough that it hasnt been implemented.
Note that these musing are trying to adress a yet far more general
problem of specifying arbitrary types constraints on anything; I am
primarily interested in specifying container types in the special case
of collection packing/unpacking syntax, with further extensions
nothing but a welcome addon. The fact that the former was judged
infeasible does not mean the more modest goal of the latter might not
be attainable.


> > *even though the asteriks syntax is infact a limited form of exactly
> > that
>
> It absolutely is not. def f(*args, **kwargs) constructs a tuple and a
> dict, it does not type-check that the function is passed a tuple and a
> dict as arguments. These are completely different things.

Which is of course not something I ever proposed; I never said
anything about checking types of existing data; im talking about
coercing types of newly created data, like the target of a collection
packing. That is exactly what *args and **kwargs also do.

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

#17122

On Tue, 13 Dec 2011 01:15:46 -0800, Eelco wrote:

> On Dec 13, 3:43 am, Steven D'Aprano <steve
> +comp.lang.pyt...@pearwood.info> wrote:
>> 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.
[...]
> We are not talking mathemathics, we are talking programming languages.

What *I* am talking about is your assertion that there is only one 
possible meaning for "equals" in the context of a programing language. 
This is *simply not correct*.

You don't have to believe me, just look at the facts. It's hard to find 
languages that use the word "equals" (or very close to it) rather than 
equals signs, but here are four languages which do:

(1) OpenXION:

Equals in OpenXION is weakly typed, like Perl:

>1 + 1.0 equals "2"
true


(2) C# uses method notation: a.Equals(b) can be overridden, but for many 
types it defaults to value equality, that is, the equivalent to Python's 
a == b.

(3) Ruby uses a.equal?(b) for "reference equality", that is, the 
equivalent of Python's "is" operator:

irb(main):001:0> a = "abc"
=> "abc"
irb(main):002:0> b = "abc"
=> "abc"
irb(main):003:0> a.equal?(b)
=> false
irb(main):004:0> a == b
=> true


(4) Mathematica's Equal[x, y] can test values and expressions for 
equality. It may return true, false, or unevaluated (i.e. itself).


Four languages that use Equals (or close to it) with four different 
behaviours.



> Identity versus value equality is a well established concept within its
> jargon. Within this context, 'equals' and 'is' have clearly defined
> meanings. 

Incorrect. Most programming languages do not even have a concept of 
identity: identity is only(?) relevant to reference languages, like 
Python, where variables are references to objects.

Even for languages that have a concept of identity, most don't don't call 
it "is". Objective-C calls it "==", PHP calls it "===", C# calls it 
object.ReferenceEquals. (Python, Algol 68, and VB .NET are three which do 
call it "is".)

For stack-based languages like Forth, it doesn't even make sense to talk 
about identity, since values aren't variables: they're just values on a 
stack, not values in a fixed location, or bound to a known name.

Again, all this goes to demonstrate that the language designer is free to 
choose any behaviour they like, and give it any name they like.


[...]
> So 'frequency of use' is no valid interpretation of 'obscurity'? Im not
> a native speaker, but im pretty sure it is.

No. Things which are obscure are used in language infrequently, because 
if they were common they would not be obscure. But things which are used 
infrequently are not necessarily obscure.

An example in common language: "Napoleon Bonaparte" does not come up in 
conversation very frequently, but he is not an obscure historical figure.

An example from programming: very few people need to use the 
trigonometric functions sin, cos, tan in their code. But they are not 
obscure functions: most people remember them from school. People who have 
forgotten almost everything about mathematics except basic arithmetic 
probably remember sin, cos and tan. But they never use them.



>> >> 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.
> 
> Of course I was being silly; I know this use is following a historical
> precedent; but id rather see it rectified in the previous version of
> python rather than the next. My sillyness was prompted by the percieved
> pointlessness of your remark. Of course python is not trying to be
> backwards compatible with C; so why bring it up then?

Because you asked why Python uses the % operator for remainder.


[...]
> They are bad ideas because they truely do not lead to the execution of
> different code, but are merely a reordering, mixing statements in with a
> function declaration. I am proposing no such thing; again, the type(arg)
> notation I have dropped, and never was meant to have anything to do with
> function calling; it is a way of supplying an optional type constraint,
> so in analogy with function annotations, I changed that to arg::type.
> Again, this has nothing to do with calling functions on arguments.

You have not thought about this carefully enough. Consider what happens 
when this code gets called:

def f(*args): pass

f(a, b, c)


The Python virtual machine (interpreter, if you prefer) must take three 
arguments a, b, c and create a tuple from them. This must happen at 
runtime, because the value of the objects is not known at compile time. 
So at some point between f(a, b, c) being called and the body of f being 
entered, a tuple must be created, and the values of a, b, c must be 
collated into a single tuple.

Now extend this reasoning to your proposal:

def f(args:FOO): pass

At runtime, the supplied arguments must be collated into a FOO, whatever 
FOO happens to be. Hence, the function that creates FOO objects must be 
called before the body of f can be entered. This doesn't happen for free. 
Whether you do it manually, or have the Python interpreter do it, it 
still needs to be done.

 
> First off, type constraints must have some use; all those languages cant
> be wrong.

But you're not talking about type constraints. You're not instructing the 
function to reject arguments which have the wrong type, you are 
instructing it to collate multiple arguments into a list (instead of a 
tuple like Python currently does). def f(*args) *constructs* a tuple, it 
doesn't perform a type-check.




-- 
Steven

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

#17132

On 13 dec, 12:13, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> On Tue, 13 Dec 2011 01:15:46 -0800, Eelco wrote:
> > On Dec 13, 3:43 am, Steven D'Aprano <steve
> > +comp.lang.pyt...@pearwood.info> wrote:
> >> 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.
> [...]
> > We are not talking mathemathics, we are talking programming languages.
>
> What *I* am talking about is your assertion that there is only one
> possible meaning for "equals" in the context of a programing language.
> This is *simply not correct*.
>
> You don't have to believe me, just look at the facts. It's hard to find
> languages that use the word "equals" (or very close to it) rather than
> equals signs, but here are four languages which do:

That python is not the only language to not get this quite as right as
could be is known to me. But within computer science as a discipline,
equality and identity comparisons have a clear enough meaning. 'is'
has a narrower meaning than 'equals'. '==' has no meaning whatsoever
in computer science.

> Again, all this goes to demonstrate that the language designer is free to
> choose any behaviour they like, and give it any name they like.

Certainly you demonstrated as much. Programming languages are created
by people, and they have a tendency to make mistakes, and to have to
compromise (backwards compatibility, and so on). Thats a seperate
matter from 'what ought to be done', when discussing optimal language
design.

> > So 'frequency of use' is no valid interpretation of 'obscurity'? Im not
> > a native speaker, but im pretty sure it is.
>
> No. Things which are obscure are used in language infrequently, because
> if they were common they would not be obscure. But things which are used
> infrequently are not necessarily obscure.
>
> An example in common language: "Napoleon Bonaparte" does not come up in
> conversation very frequently, but he is not an obscure historical figure.
>
> An example from programming: very few people need to use the
> trigonometric functions sin, cos, tan in their code. But they are not
> obscure functions: most people remember them from school. People who have
> forgotten almost everything about mathematics except basic arithmetic
> probably remember sin, cos and tan. But they never use them.

I dont think its terribly interesting to debate whether the term
obscure applies to trigonometric functions or not: the important
matter is that they are where they should be; under math.cos, etc.
They dont have their own special character, and I hope you agree that
is as it should be.

I use trig far more often than modulus, so that argues in favor of
modulus being under math too; infact I used modulus quite recently,
but naturally it was in a piece of code that should be done in C
eventually anyway (evaluating subdivision surfaces)

> Because you asked why Python uses the % operator for remainder.

So you ARE implying python has backwards compatibility with C as a
design goal? Otherwise the given answer to this question is
nonsensical.

>
> [...]
>
> > They are bad ideas because they truely do not lead to the execution of
> > different code, but are merely a reordering, mixing statements in with a
> > function declaration. I am proposing no such thing; again, the type(arg)
> > notation I have dropped, and never was meant to have anything to do with
> > function calling; it is a way of supplying an optional type constraint,
> > so in analogy with function annotations, I changed that to arg::type.
> > Again, this has nothing to do with calling functions on arguments.
>
> You have not thought about this carefully enough. Consider what happens
> when this code gets called:
>
> def f(*args): pass
>
> f(a, b, c)
>
> The Python virtual machine (interpreter, if you prefer) must take three
> arguments a, b, c and create a tuple from them. This must happen at
> runtime, because the value of the objects is not known at compile time.
> So at some point between f(a, b, c) being called and the body of f being
> entered, a tuple must be created, and the values of a, b, c must be
> collated into a single tuple.
>
> Now extend this reasoning to your proposal:
>
> def f(args:FOO): pass
>
> At runtime, the supplied arguments must be collated into a FOO, whatever
> FOO happens to be. Hence, the function that creates FOO objects must be
> called before the body of f can be entered. This doesn't happen for free.
> Whether you do it manually, or have the Python interpreter do it, it
> still needs to be done.

Of course the python interpreted needs to do this; and in case non-
builtin types are allowed, the mechanism is going to be through their
constructor. But thats a detail; the syntax doesnt say: 'please call
this constructor for me', any more than **kwargs says 'please call a
dict constructor for me', even though equivalent operations are
obviously going on under the hood as part of the process. Yes,
whatever type you have needs to be constructed, and its not magically
going to happen, its going to cost CPU cycles. The question is, do you
end up constructing both a tuple and a list, or do you construct the
list directly?


> > First off, type constraints must have some use; all those languages cant
> > be wrong.
>
> But you're not talking about type constraints. You're not instructing the
> function to reject arguments which have the wrong type, you are
> instructing it to collate multiple arguments into a list (instead of a
> tuple like Python currently does). def f(*args) *constructs* a tuple, it
> doesn't perform a type-check.

I am talking about type constraints, but as seems to be the usual
pattern in our miscommunications, you seek to attach a specific far
fetched meaning to it that I never intended. Insofar as I understand
these terms, a type-constraint is part of a declaration; float x; in C-
family languages, args::list in python 4 perhaps. It narrows down the
semantics for further usage of that symbol. A type-check is something
along the lines of type(args)==list, a runtime thing and something
completely different. I havnt mentioned the latter at all, explicitly
or implicitly, as far as im aware.

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

#17133

On Tue, Dec 13, 2011 at 11:47 PM, Eelco <hoogendoorn.eelco@gmail.com> wrote:
>> def f(*args) *constructs* a tuple, it
>> doesn't perform a type-check.
>
> I am talking about type constraints... A type-check is something
> along the lines of type(args)==list, a runtime thing and something
> completely different. I havnt mentioned the latter at all, explicitly
> or implicitly, as far as im aware.

I'm not sure what you mean by a "type constraint". Here's how I understand such:

float|int foobar; //Declare that the variable 'foobar' is allowed to
hold a float or an int
foobar = 3.2; //Legal.
foobar = 1<<200; //Also legal (a rather large integer value)
foobar = "hello"; //Not legal

Python doesn't have any such thing (at least, not in-built). Any name
may be bound to any value - or if you like, any variable can contain
any type. Same applies to argument passing - you can even take an
unbound method and call it with some completely different type of
object as its first parameter. (I can't think of ANY situation in
which this would not be insanely confusing, tbh.) When you gather a
function's arguments into a tuple, list, or any other such container
object, what you're doing is constructing another object and stuffing
it with references to the original arguments. That involves building a
new object, where otherwise you simply bind the arguments' names to
the original objects directly.

Now, it is perfectly conceivable to have designed Python to _always_
pass tuples around. Instead of a set of arguments, you just always
pass exactly one tuple to a function, and that function figures out
what to do with the args internally. If that's the way the language is
built, then it is the _caller_, not the callee, who builds that tuple;
and we still have the same consideration if we want a list instead.

So suppose you can have a user-defined object type instead of
list/dict. How are you going to write that type's __init__ function?
Somewhere along the way, you need to take a variable number of
arguments and bundle them up into a single one... so somewhere, you
need the interpreter to build it for you. This is going to end up
exactly the same as just accepting the tuple and then passing that to
a constructor, like the list example. Keep things transparent and you
make debugging a LOT easier.

ChrisA

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

#17136

On 13 dec, 14:14, Chris Angelico <ros...@gmail.com> wrote:
> On Tue, Dec 13, 2011 at 11:47 PM, Eelco <hoogendoorn.ee...@gmail.com> wrote:
> >> def f(*args) *constructs* a tuple, it
> >> doesn't perform a type-check.
>
> > I am talking about type constraints... A type-check is something
> > along the lines of type(args)==list, a runtime thing and something
> > completely different. I havnt mentioned the latter at all, explicitly
> > or implicitly, as far as im aware.
>
> I'm not sure what you mean by a "type constraint". Here's how I understand such:
>
> float|int foobar; //Declare that the variable 'foobar' is allowed to
> hold a float or an int
> foobar = 3.2; //Legal.
> foobar = 1<<200; //Also legal (a rather large integer value)
> foobar = "hello"; //Not legal
>
> Python doesn't have any such thing (at least, not in-built).

Agreed on what a type constraint is, and that python does not really
have any, unless one counts the current use of asterikses, which are
infact a limited form of type constrait (*tail is not just any object,
but one holding a list, which modifies the semantics of the assignment
statement 'head,*tail=sequence' from a regular tuple unpacking to a
specific form of the more general collection unpacking syntax);

The idea is to enrich this syntax; to add optional and limited type
constraints to python, specifically to enrich collection packing/
unpacking syntax, but perhaps the concept can be further generalized.


> So suppose you can have a user-defined object type instead of
> list/dict. How are you going to write that type's __init__ function?
> Somewhere along the way, you need to take a variable number of
> arguments and bundle them up into a single one... so somewhere, you
> need the interpreter to build it for you. This is going to end up
> exactly the same as just accepting the tuple and then passing that to
> a constructor, like the list example. Keep things transparent and you
> make debugging a LOT easier.

Agreed; for user defined collection types there would not be a
performance benefit over converting a tuple, since this is exactly
what will happen anyway, but for collection types derived from any of
the builtins, python could optimize away the intermediate and
construct the desired collection type directly from the available
information.

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

#17079

Steven D'Aprano wrote:

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

    	Anytime you can blame C for something, you can also blame a bunch 
of other languages for foolishly perpetuating the inanities of C.

-- 
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is
no path, and leave a trail."
	--author unknown

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

#17029

Eelco Hoogendoorn writes:

> 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 modulus is not the result but one of the arguments: when numbers x
and y are congruent modulo n (stated in terms of the modulo operation:
x mod n = y mod n), the modulus is n. A word for x mod n is remainder.

I agree about the obscurity of using the percent sign as the operator.

A quick google suggests that your use of 'modulus' is now popular
among programmers. Past experience in mathematics newsgroups tells me
that some mathematicians do not accept the existence of any remainder
operator at all. Honest. (I see them but I cannot understand them.)

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

#17031

> The modulus is not the result but one of the arguments: when numbers x
> and y are congruent modulo n (stated in terms of the modulo operation:
> x mod n = y mod n), the modulus is n. A word for x mod n is remainder.
>
> I agree about the obscurity of using the percent sign as the operator.
>
> A quick google suggests that your use of 'modulus' is now popular
> among programmers. Past experience in mathematics newsgroups tells me
> that some mathematicians do not accept the existence of any remainder
> operator at all. Honest. (I see them but I cannot understand them.)

You are correct; the thing it computes is the remainder, not the
modulus. Nonetheless, 'x modulus y' is how it is put in natural
language, but I suppose math.remainder would be my preferred place to
put this.

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

#17033

Eelco writes:

> > The modulus is not the result but one of the arguments: when numbers x
> > and y are congruent modulo n (stated in terms of the modulo operation:
> > x mod n = y mod n), the modulus is n. A word for x mod n is remainder.
> >
> > I agree about the obscurity of using the percent sign as the operator.
> >
> > A quick google suggests that your use of 'modulus' is now popular
> > among programmers. Past experience in mathematics newsgroups tells me
> > that some mathematicians do not accept the existence of any remainder
> > operator at all. Honest. (I see them but I cannot understand them.)
> 
> You are correct; the thing it computes is the remainder, not the
> modulus. Nonetheless, 'x modulus y' is how it is put in natural
> language, but I suppose math.remainder would be my preferred place to
> put this.

I think it's 'x modulo y', which matches 'x and y are congruent modulo
z', but now I fear that programming people have been developing a
different habit.

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

#17032

By the way...

Is there any particular reason why some of my replies do not show up
on groups.google, and some of them do not show up on mail.python.org?
Sorry to annoy people with reposting, but im going to be forced to do
some of that until this is cleared up....

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

#17048

On 12/12/2011 5:59 AM, Jussi Piitulainen wrote:


> Past experience in mathematics newsgroups tells me
> that some mathematicians do not accept the existence of any remainder
> operator at all.

Even though they carry hour/minute/second remindering devices on their 
bodies and put year/month/day remaindering devices on their wall? 
'Twould be strange indeed!

-- 
Terry Jan Reedy

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

#17064

Terry Reedy writes:
> On 12/12/2011 5:59 AM, Jussi Piitulainen wrote:
> 
> > Past experience in mathematics newsgroups tells me
> > that some mathematicians do not accept the existence of any remainder
> > operator at all.
> 
> Even though they carry hour/minute/second remindering devices on their
> bodies and put year/month/day remaindering devices on their wall?
> 'Twould be strange indeed!

They recognize modular arithmetic but for some reason insist that
there is no such _binary operation_. But as I said, I don't understand
their concern. (Except the related concern about some programming
languages, not Python, where the remainder does not behave well with
respect to division.)

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

#17066

> They recognize modular arithmetic but for some reason insist that
> there is no such _binary operation_. But as I said, I don't understand
> their concern. (Except the related concern about some programming
> languages, not Python, where the remainder does not behave well with
> respect to division.)

They might not be willing to define it, but as soon as we programmers
do, well, we did.

Having studied the contemporary philosophy of mathematics, their
concern is probably that in their minds, mathematics is whatever some
dead guy said it was, and they dont know of any dead guy ever talking
about a modulus operation, so therefore it 'does not exist'.

Whatever you want to call the concept we are talking about, or whether
you care to talk about it at all, it is most certainly a binary
operation, since there are two arguments involved. There is no way
around that.

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

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

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

csiph-web