On 09/29/2010 08:50 PM, Raymond Hettinger wrote:
> 1. Liberalize setobject.c binary operator methods to accept anything
> registered to the Set ABC and add a backwards incompatible restriction
> to the Set ABC binary operator methods to only accept Set ABC
> instances (they currently accept any iterable).
>
> This approach has a backwards incompatible tightening of the Set ABC,
> but that will probably affect very few people. It also has the
> disadvantage of not providing a straight-forward way to handle general
> iterable arguments (either the implementer needs to write named binary
> methods like update, difference, etc for that purpose or the user will
> need to cast the the iterable to a set before operating on it). The
> positive side of this option is that keeps the current advantages of
> the setobject API and its NotImplemented return value.
>
> 1a. Liberalize setobject.c binary operator methods, restrict SetABC
> methods, and add named methods (like difference, update, etc) that
> accept any iterable.
I prefer 1 to 1a, but either is acceptable. 1 just forces you to call
set() on your iterable before operating on it, which I think helps
("explicit is better than implicit").
In 1a, by "add named methods that accept any iterable", you mean add
those to the SetABC? If so, then I'm more strongly for 1 and against
1a. I'm not convinced all classes implementing the Set ABC should have
to implement all those methods.
/larry/
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