[Python-ideas] Marking keyword arguments (was: f-string, for dictionaries)

[Sven R. Kunze]

Hi Michel,
hi Paul,

sorry for hijacking this thread somewhat. I would like to extend this 
proposal a bit in order make it useful for a broader audience and to 
provide a real-word use-case. So, this post is just to gather general 
acceptance and utility of it.


Michel, you specifically mentioned dicts as the place where to start 
with this kind of syntax. I have to tell you one could easily extend 
this thought process to function calls as well.

Keyword arguments cannot be simply passed like positional arguments. 
They always require the parameter name to be mentioned.


In production we have masses of code that goes like this:

 >>> do_thing(important_stuff=important_stuff, request=request)
 >>> make_any(config=123, important_stuff=important_stuff, 
other_form=other_form)


Causes:
- verbose names of variables
- extended usage of kwargs
- passing the same data over and over again down the calling hierarchy


So, instead providing this kind of syntax for dicts only, why not also 
providing them for kwargs? Basically marking arguments as keyword arguments:


my_func(:param1, :param2)


":param" equals "param=param" again but as already said that might just 
be placeholder syntax.


What do you think?



On 25.10.2016 23:18, Michel Desmoulin wrote:
>
>
> Le 25/10/2016 à 22:27, Paul Moore a écrit :
>> On 25 October 2016 at 20:11, Michel Desmoulin
>> <desmoulinmichel at gmail.com> wrote:
>>> Similarly, I'd like to suggest a similar feature for building
>>> dictionaries:
>>>
>>>>>> foo = 1
>>>>>> bar = 2
>>>>>> {:bar, :foo}
>>> {'bar': 1, 'foo', 2}
>>
>> I don't see a huge advantage over
>>
>>>>> dict(foo=foo, bar=bar)
>>
>> Avoiding having to repeat the variable names doesn't feel like a
>> killer advantage here, certainly not sufficient to warrant adding yet
>> another dictionary construction syntax. Do you have examples of code
>> that would be substantially improved with this syntax (over using an
>> existing approach)?
>
> {:bar, :foo}
> vs
> dict(foo=foo, bar=bar)
>
> has the same benefit that would have
>
> f"hello {foo} {bar}"
> vs
> "hello {} {}".format(foo, bar)
>
>>
>>> And a similar way to get the content from the dictionary into variables:
>>>
>>>>>> values = {'bar': 1, 'foo', 2}
>>>>>> {:bar, :foo} = values
>>>>>> bar
>>> 1
>>>>>> foo
>>> 2
>>
>> There aren't as many obvious alternative approaches here, but it's not
>> clear why you'd want to do this. So in this case, I'd want to see
>> real-life use cases. Most of the ones I can think of are just to allow
>> a shorter form for values['foo']. For those uses
>>
>>     >>> from types import SimpleNamespace
>>     >>> o = SimpleNamespace(**values)
>>     >> o.foo
>>     1
>>
>> works pretty well.
>
> This is just unpacking for dicts really.
>
> As you would do:
>
> a, b = iterable
>
> you do:
>
> {:a, :b} = mapping
>
>>
>>> The syntaxes used here are of course just to illustrate the concept
>>> and I'm
>>> suggesting we must use those.
>>
>> Well, if we ignore the syntax for a second, what is your proposal
>> exactly? It seems to be in 2 parts:
>>
>> 1. "We should have a dictionary building feature that uses keys based
>> on variables from the local namespace". OK, that's not something I've
>> needed much, and when I have, there have usually been existing ways to
>> do the job (such as dict(foo=foo) noted above) that are perfectly
>> sufficient. Sometimes the existing alternatives look a little clumsy
>> and repetitive, but that's a very subjective judgement, and any new
>> syntax could easily look worse to me (your specific proposal, for
>> example, does). So I can see a small potential benefit in (subjective)
>> readability, but that's offset by the proposal being another way of
>> doing something that's already pretty well covered in the language.
>> Add to that all of the "normal" objections to new syntax (more to
>> teach/learn, hard to google, difficulty finding a form that suits
>> everyone, etc) and it's hard to see this getting accepted.
>>
>> 2. "We should have a way of unpacking a dictionary into local
>> variables". That's not something that I can immediately think of a way
>> of doing currently - so that's a point in its favour. But honestly,
>> I've never seen the need to do this outside of interactive use (for
>> which see below). If all you want is to avoid the d['name'] syntax,
>> which is quite punctuation-heavy, the SimpleNamespace trick above does
>> that. So there's almost no use case that I can see for this. Can you
>> give examples of real-world code where this would be useful?
>>
>> On the other hand, your proposal, like many that have come up
>> recently, seems to be driven (if it's OK for me to guess at your
>> motivations) by an interest in being able to write relatively terse
>> one-liners, or at least to avoid some of the syntactic overheads of
>> existing constructs. It seems to me that the environment I'd most want
>> to do this in is the interactive interpreter. So I wonder if this (and
>> similar) proposals are driven by a feeling that it's "clumsy" writing
>> code at the interactive prompt. That may well be so. The standard
>> interactive prompt is pretty basic, and yet it's a *huge* part of the
>> unique experience working with Python to be able to work at the prompt
>> as you develop. So maybe there's scope for discussion here on
>> constructs focused more on interactive use? That probably warrants a
>> separate thread, though, so I'll split it off from this discussion.
>> Feel free to contribute there if I'm right in where I think the
>> motivation for your proposals came from.
>>
>> Paul
>
>
> Currently I already have shortcuts those features.
>
> I have wrappers for dictionaries such as:
>
> d(mapping).unpack('foo', 'bar')
>
> Which does some hack with stack frame and locals().
>
> And:
>
> d.from_vars('foo', 'bar')
>
> I use them only in the shell of course, because you can't really have
> such hacks in production code.
>
> I would use such features in my production code if they was a clean way
> to do it.
>
> It's just convenience syntaxic sugar.
>
> You can argue that decorator could be written:
>
> def func():
>     pass
>
> func = decorator(func)
>
> Instead of:
>
> @decorator
> def func():
>    pass
>
> But the second one is more convenient. And so are comprehensions,
> unpacking, and f-strings. Clearly not killer features, just nice to have.
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/