These were exactly my thoughts. I wanted to bump this, since it was drowned out by more important things like Paths and invertible booleans and almost no discussion was had on the main issue, that of dict views not acting like sets. Since things have died down, is that behavior that should be remedied, and if so should it be backwards compatible (make set more permissive), treat it as a bugfix (make the views raise errors)? And should it include union/other methods to keep performance on the usecase that now throws a bug?

-Josh

On Thu, Apr 7, 2016 at 1:53 PM Michael Selik <mike@selik.org> wrote:

> On Apr 6, 2016, at 10:38 AM, Joshua Morton <joshua.morton13@gmail.com> wrote:
>     set() | []  # 2
>     {}.keys() | []  # 3

Looks like this should be standardized. Either both raise TypeError, or both return a set. My preference would be TypeError, but that might be worse for backwards-compatibility.

>     {}.keys().union(set())  # 6

Seems to me that the pipe operator is staying on MappingView, so it's reasonable to add a corresponding ``.union`` to mimic sets. And intersection, etc.

>     {}.values() == {}.values()  # 9
>     d = {}; d.values() == d.values()  # 10

It's weird, but float('nan') != float('nan'). I'm not particularly bothered by this.