[Python-ideas] Short form for keyword arguments and dicts
Joshua Landau
joshua.landau.ws at gmail.com
Thu Jun 27 15:05:15 CEST 2013
On 27 June 2013 13:55, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 27 June 2013 22:10, Joshua Landau <joshua.landau.ws at gmail.com> wrote:
>> I would *never* have thought that:
>>
>> func(*, arg): pass
>>
>> meant
>>
>> func(arg=arg): pass
>
> It doesn't mean that, since a bare keyword-only argument *must* be
> passed in when calling the function (as it has no default value).
>
>> despite that I sort of get the *very slight* (but not really even
>> that) symmetry (now that you've explained it).
>
> The "*" in the keyword-only parameter syntax still refers to
> positional argument packing. It just leaves the destination undefined
> to say "no extra positional arguments are allowed" rather than "any
> extra positional arguments go here".
>
> The parameters that appear after that entry are keyword only solely by
> a process of elimination - if all the positional arguments have been
> consumed (or disallowed), then any parameters that are left *have* to
> be passed as keywords, since positional and keyword are the only two
> argument passing options we offer.
>
> On the calling side, we've actually toyed with the idea of removing
> the argument ordering restrictions, because they imply a parallel with
> the parameter definitions that doesn't actually exist. We haven't
> though, as it's significant extra work for no compelling benefit.
I... don't understand. Did you perhaps misread my post?
To reiterate, in shorthand, I am arguing against (I think -- if you
are right then I've no idea what's actually happening).:
foo(*, bar, spam)
meaning
foo(bar=bar, spam=spam)
partially by pointing out that it isn't symmetrical with
def foo(*, bar, spam): ...
which means nothing of the sort.
Of course, if I'm the one confused then I'm afraid that I just have no
idea what I'm on about.
> As far as this whole thread goes, though, we're still in the situation
> where the simplest mechanisms Python currently has to extract a submap
> from a mapping are a dict comprehension and operator.itemgetter.
Thank you for stating that root of the problem that I've had on the
tip of my tongue.
Perhaps: "dict & set" or even "dict & iter" would work, although it
looks unwieldy, and I'm not sure I like it.
> These
> proposed changes to function calling syntax then target a very niche
> case of that broader problem, where the mapping is specifically the
> current local variables and the destination for the submap is a
> function call with like named parameters. This is *not* the calibre of
> problem that prompts us to make Python harder to learn by adding new
> syntax.
More information about the Python-ideas
mailing list