Le 25/10/2016 à 22:27, Paul Moore a écrit :
On 25 October 2016 at 20:11, Michel Desmoulin <desmoulinmic...@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@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
