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

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 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@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/