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

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

Re: Verbose and flexible args and kwargs syntax

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Verbose and flexible args and kwargs syntax Chris Angelico <rosuav@gmail.com> - 2011-12-11 22:15 +1100
    Re: Verbose and flexible args and kwargs syntax Duncan Booth <duncan.booth@invalid.invalid> - 2011-12-11 12:39 +0000
      Re: Verbose and flexible args and kwargs syntax Chris Angelico <rosuav@gmail.com> - 2011-12-12 00:09 +1100
      Re: Verbose and flexible args and kwargs syntax Christian Heimes <lists@cheimes.de> - 2011-12-11 14:14 +0100

#16980 — Re: Verbose and flexible args and kwargs syntax

On Sun, Dec 11, 2011 at 9:49 PM, Eelco Hoogendoorn
<hoogendoorn.eelco@gmail.com> wrote:
> Problems im still wrestling with: the same syntax could not be used when
> calling a function; that lack of symmetry would make things more confusing,
> not less.

That symmetry is a large factor, IMHO. I can write a wrapper function like this:

def fixedargs(x,y,z):
    return wrappedfunc(x,y,z)

Or like this:

def anyargs(*args,**kwargs):
    return wrappedfunc(*args,**kwargs)

Either way, it's a perfect parallel, and that's very useful for noticing errors.

With a keyworded syntax, that's going to be a lot harder.

Another issue: You suggest being able to use "attrdict" or some other
dict subclass. This means that, rather than being a language
construct, this will involve a name lookup. And what happens if you
have a class that subclasses both list and dict? Will it get the
positional args, the keyword args, or both?

Laudable notion, but I'm not sure that it'll actually work in practice.

ChrisA

[toc] | [next] | [standalone]

#16982

Chris Angelico <rosuav@gmail.com> wrote:
> Either way, it's a perfect parallel, and that's very useful for
> noticing errors. 
> 
> With a keyworded syntax, that's going to be a lot harder.

If it used keywords then you could keep symmetry quite easily:

    def anyargs(arglist args, argdict kwargs):
        return wrappedfunc(arglist args, argdict kwargs)

and you would have the advantage of two new keywords that people could 
actually search on.

> 
> Another issue: You suggest being able to use "attrdict" or some other
> dict subclass. This means that, rather than being a language
> construct, this will involve a name lookup. And what happens if you
> have a class that subclasses both list and dict? Will it get the
> positional args, the keyword args, or both?

Irrelevant, you can't subclass both list and dict:

>>> class C(list, dict): pass

Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    class C(list, dict): pass
TypeError: multiple bases have instance lay-out conflict



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

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

#16983

On Sun, Dec 11, 2011 at 11:39 PM, Duncan Booth
<duncan.booth@invalid.invalid> wrote:
> Chris Angelico <rosuav@gmail.com> wrote:
> If it used keywords then you could keep symmetry quite easily:
>
>    def anyargs(arglist args, argdict kwargs):
>        return wrappedfunc(arglist args, argdict kwargs)
>
> and you would have the advantage of two new keywords that people could
> actually search on.

Yes, that's just a strict keywordification of the * and ** symbols.
The same argument could be made for eliminating the standard algebraic
+ operator and replacing it with a keyword "__add__". I don't think
that's worthwhile.

The OP suggested using 'dict' and 'list' themselves as the keywords,
thus allowing the use of subclasses. This would make it unsearchable,
or else rather verbose:

def anyargs(pack list args, pack dict kwargs):
    return wrappedfunc(pack list args, pack dict kwargs)

With this syntax, what happens if you muck up list/dict? Or
alternatively, the briefer syntax:

def anyargs(pack list args, pack dict kwargs):
    return wrappedfunc(pack args, pack kwargs)

 which breaks the symmetry, and doesn't say which one you're doing -
for instance, if you only use one out of list and dict args, it would
make sense to have a variable "options" or "args" that gets unpacked
to the function's arguments - and there's no way to see whether it's
going to be keyword or positional.

The verbose syntax has a lot going for it, but it's rather verbose.
Why say "pack list args" when you can just say "*args"? Compare
initializer syntax between Python and PHP:

foo = ["asdf", "qwer", {1:2, 3:4}]

$foo = array("asdf", "qwer", array(1=>2, 3=>4))

Is it more Pythonic to use explicitly-named types, or to have simple
notation that's clear and easy to read? Or is this a matter for
personal preference?

>> Another issue: You suggest being able to use "attrdict" or some other
>> dict subclass. This means that, rather than being a language
>> construct, this will involve a name lookup. And what happens if you
>> have a class that subclasses both list and dict? Will it get the
>> positional args, the keyword args, or both?
>
> Irrelevant, you can't subclass both list and dict:
> TypeError: multiple bases have instance lay-out conflict

Ah. Curious. I've not done much with multiple inheritance in Python
(come to think of it, I don't recall when I last used MI in _any_
language). In any case, there's still the potential unclarity as to
_which_ of dict and list is the one that's been inherited, which
requires a run-time lookup to solve.

ChrisA

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

#16984

Am 11.12.2011 13:39, schrieb Duncan Booth:
>> Another issue: You suggest being able to use "attrdict" or some other
>> dict subclass. This means that, rather than being a language
>> construct, this will involve a name lookup. And what happens if you
>> have a class that subclasses both list and dict? Will it get the
>> positional args, the keyword args, or both?
> 
> Irrelevant, you can't subclass both list and dict:

But you can fake it with __instancecheck__ and __subclasscheck__ methods.

Christian

[toc] | [prev] | [standalone]

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

csiph-web