[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