On Thu, Feb 6, 2020 at 7:42 PM Musbur <mus...@posteo.org> wrote:
>
> Depends on what d is.
>
> >>> type({})
> <class 'dict'>
>
> So the result is {(1, 2): None}, but the ambiguity comes from the
> definition of {}, not from my proposal.
>
Actually, what Serhiy hinted at was a consequence (and, I would say, a
rather weird corner case) of the current definition of |= as being
"equivalent to update()". Since update() will accept a number of
things, including an iterable of pairs, it's actually possible to use
a set of two-element tuples as a representation of keys and values. It
seems pretty unlikely that anyone would use a *set* for this (as
opposed to, say, a list or generator), but it does mean that your
proposal would conflict with that. Which in turn means you're actually
asking for |= to special-case sets; not impossible, by any means, but
it's a definite change and not simply a logical extension of current
behaviour.
I don't think supporting sets in |= is worth this confusion,
especially since there's no easy way to override the choice of value.
It'd be just as easy to do thing|=dict.fromkeys(s) and avoid the whole
issue. However, IMO the &= operator would be better able to accept a
set, and this is something that wouldn't conflict (and thus can be
safely added later).
ChrisA
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/BTYIZSBWR3O5JRIGFHOZWVIPUISUGDHB/
Code of Conduct: http://python.org/psf/codeofconduct/
