[Python-ideas] f-string, for dictionaries

[Michel Desmoulin]

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.