[issue33874] dictviews set operations do not follow pattern of set or frozenset
Forest added the comment:
Thank you very much for thorough explanation! It really helped me
understand the issue.
Since this is the intended behavior, would it be good to add some tests for
the behavior? I would have found those tests helpful in working on
https://bugs.python.org/issue27575
If so, I'm happy to prepare a PR for adding some tests for this behavior.
On Sat, Jun 16, 2018 at 2:22 AM Raymond Hettinger
wrote:
>
> Raymond Hettinger added the comment:
>
> It's true the concrete set API differs in some ways from the Set abstract
> base class followed by dictviews. The concrete set-to-set operators are
> restricted to only work with other sets, leaving the named set methods
> (union, intersection, difference, etc) to accept any iterable. In
> contrast, the Set abstract base class only has operators and those are
> specifically allowed to accept any iterable.
>
> It may not seem harmonious, but those were intentional and long-standing
> design decisions. The restriction on concrete set operators to only work
> with other sets can be traced back to bad experiences with the += operator
> for lists accepting any iterable (allowing mistakes like s+='abc' when
> s.append('abc') was intended).
>
> Different choices were made in the design of the abstract Set API. In
> order to be useful, that API can't make as strong of a restriction, so it
> allows any iterable to be used as inputs to the operators. Also note that
> the abstract Set API doesn't have the named set methods (union,
> intersection, difference, etc), so the burden of falls on the operators to
> support iterables. IIRC, the reason that the named set methods were
> omitted was to make it easier to implement conforming classes that could
> interoperate with one another. For more details on the design of the
> collections ABCs, see Guido's PEP on the subject (that's where he explains
> was problem the abstract classes where intended to solve and some of design
> considerations).
>
> One can argue with those design decisions, but that ship sailed a long
> time ago and it would no longer be possible to change either set or Set
> without breaking existing code. The existing behaviors are intentional,
> venerable, tested, and guaranteed.
>
> --
> nosy: +rhettinger
> resolution: -> not a bug
> stage: -> resolved
> status: open -> closed
>
> ___
> Python tracker
>
> ___
>
--
___
Python tracker
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33874] dictviews set operations do not follow pattern of set or frozenset
Raymond Hettinger added the comment:
It's true the concrete set API differs in some ways from the Set abstract base
class followed by dictviews. The concrete set-to-set operators are restricted
to only work with other sets, leaving the named set methods (union,
intersection, difference, etc) to accept any iterable. In contrast, the Set
abstract base class only has operators and those are specifically allowed to
accept any iterable.
It may not seem harmonious, but those were intentional and long-standing design
decisions. The restriction on concrete set operators to only work with other
sets can be traced back to bad experiences with the += operator for lists
accepting any iterable (allowing mistakes like s+='abc' when s.append('abc')
was intended).
Different choices were made in the design of the abstract Set API. In order to
be useful, that API can't make as strong of a restriction, so it allows any
iterable to be used as inputs to the operators. Also note that the abstract
Set API doesn't have the named set methods (union, intersection, difference,
etc), so the burden of falls on the operators to support iterables. IIRC, the
reason that the named set methods were omitted was to make it easier to
implement conforming classes that could interoperate with one another. For
more details on the design of the collections ABCs, see Guido's PEP on the
subject (that's where he explains was problem the abstract classes where
intended to solve and some of design considerations).
One can argue with those design decisions, but that ship sailed a long time ago
and it would no longer be possible to change either set or Set without breaking
existing code. The existing behaviors are intentional, venerable, tested, and
guaranteed.
--
nosy: +rhettinger
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33874] dictviews set operations do not follow pattern of set or frozenset
Forest added the comment:
Issue https://bugs.python.org/issue24413 also flags a difference in the
behavior between dictviews and sets/frozensets.
"for non-iterable object x, set().__or__(x) raises NotImplementedError, but
{}.keys().__or__(x) raises TypeError"
Issue https://bugs.python.org/issue33874 added a number of tests for dictview
set operators, but none covering the examples raised here.
--
___
Python tracker
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33874] dictviews set operations do not follow pattern of set or frozenset
Forest added the comment:
Sorry there was a typo in the first example block:
It should be
>>> {}.keys() & []
set()
>>> set() & []
Traceback (most recent call last):
File "", line 1, in
TypeError: unsupported operand type(s) for &: 'set' and 'list'
>>> set() & [] does **not** return set() it raises a TypeError
--
___
Python tracker
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33874] dictviews set operations do not follow pattern of set or frozenset
New submission from Forest :
Views of dictionary keys and items admit set operations, but the behavior of
operations differs significantly from that of set and frozenset.
>>> {}.keys() & []
set()
>>> set() & []
Traceback (most recent call last):
File "", line 1, in
TypeError: unsupported operand type(s) for &: 'set' and 'list'
>>> set() & []
set()
>>> {}.keys() & frozenset([])
set()
>>> frozenset([]) & {}.keys()
set()
>>> set() & frozenset([])
set()
>>> frozenset([]) & set()
frozenset()
Similar for |, ^, -
>>> [1, 2, 3] - {2:None}.keys()
{1, 3}
Is perhaps particularly surprising
The operators <, <=, >, >= do work as expected.
>>> [1, 2, 3] > {}.keys()
Traceback (most recent call last):
File "", line 1, in
TypeError: unorderable types: list() > dict_keys()
I'm not sure if these differences between dictviews and set/frozenset should be
considered bugs. If no, it may be good to document that the behavior is
different.
--
components: Library (Lib)
messages: 319696
nosy: fgregg
priority: normal
severity: normal
status: open
title: dictviews set operations do not follow pattern of set or frozenset
versions: Python 3.8
___
Python tracker
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
