On 07/28/2014 11:04 AM, Steven D'Aprano wrote:
On Mon, Jul 28, 2014 at 03:33:06PM +0000,dw+python-ideas@hmmz.org wrote:
On Tue, Jul 29, 2014 at 12:59:51AM +1000, Steven D'Aprano wrote:
>One good reason is that people are still convinced "dict(A, **B)" >makes some kind of sense.
Explain please. dict(A, **B) makes perfect sense to me, and it works perfectly too. It's a normal constructor call, using the same syntax as any other function or method call. Are you suggesting that it does not make sense?
It worked in Python 2, but Python 3 added code to explicitly prevent the kwargs mechanism from being abused by passing non-string keys. /face-palm
Ah of course! You're right, using dict(A, **B) isn't general enough. and make the language easier to write and use I'm still inclined to prefer allowing update() to accept multiple arguments:
a.update(b, c, d)
To me, the constructor and update method should be as near alike as possible. So I think if it's done in the update method, it should also work in the constructor. And other type constructors, such as list, should work in similar ways as well. I'm not sure that going in this direction would be good in the long term.
rather than a += b + c + d
which suggests that maybe there ought to be an updated() built-in, Let the bike-shedding begin: should such a thing be spelled ?
new_dict = a + b + c + d
Pros: + is short to type; subclasses can control the type of new_dict. Cons: dict addition isn't obvious.
I think it's more obvious. It only needs __add__ and __iadd__ methods to make it consistent with the list type. The cons is that somewhere someone could be catching TypeError to differentiate dict from other types while adding. But it's just as likely they are doing so in order to add them after a TypeError occurs. I think this added consistency between lists and dicts would be useful. But, Putting __add__ and __iadd__ methods on dicts seems like something that was probably discussed in length before, and I wonder what reasons where given for not doing it then. Cheers, Ron