[Python-Dev] Any grammar experts?
R. David Murray
rdmurray at bitdance.com
Mon Jan 26 22:28:24 CET 2015
On Mon, 26 Jan 2015 22:05:44 +0100, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Mon, 26 Jan 2015 12:22:20 -0800
> Ethan Furman <ethan at stoneleaf.us> wrote:
> > On 01/26/2015 12:09 PM, Antoine Pitrou wrote:
> > > On Mon, 26 Jan 2015 12:06:26 -0800
> > > Ethan Furman <ethan at stoneleaf.us> wrote:
> > >> It destroy's the chaining value and pretty much makes the improvement not an improvement. If there's a possibility that
> > >> the same key could be in more than one of the dictionaries then you still have to do the
> > >>
> > >> dict.update(another_dict)
> > >
> > > So what? Is the situation where chaining is desirable common enough?
> >
> > Common enough to not break it, yes.
>
> Really? What are the use cases?
My use case is a configuration method that takes keyword parameters.
In tests I want to specify a bunch of default values for the
configuration, but I want individual test methods to be able
to override those values. So I have a bunch of code that does
the equivalent of:
from test.support import default_config
[...]
def _prep(self, config_overrides):
config = default.config.copy()
config.update(config_overrides)
my_config_object.load(**config)
....
With the current proposal I could instead do:
def _prep(self, config_overrides):
my_config_object.load(**default_config, **config_overrides)
I suspect I have run into situations like this elsewhere as well, but
this is the one from one of my current projects.
That said, I must admit to being a bit ambivalent about this, since
we otherwise are careful to disallow duplicate argument names.
So, instead we could write:
my_config_object.load(**{**default_config, **config_overrides})
since dict literals *do* allow duplicate keys.
--David
More information about the Python-Dev
mailing list