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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4