Where should be put ABCs?
In http://bugs.python.org/issue25609 I said I wanted an ABC for context managers and a matching entry in typing. I originally suggested putting it in collections.abc <https://docs.python.org/3/library/collections.abc.html> but Raymond Hettinger pointed out that it doesn't really belong there (along with a bunch of other ABCs like Callable and Awaitable). So I opened http://bugs.python.org/issue25637 to discuss this, but I realize maybe this SIG is a better place to have a real discussion. The options I see are: 1. Ignore Raymond's objection and put it in collections.abc 2. Stick it in contextlib <https://docs.python.org/3/library/contextlib.html> 1. Directly 2. In a new contextlib.abc submodule 3. Stick in abc <https://docs.python.org/3/library/abc.html> 1. Directly 2. In some new subclass like abc.interfaces Do people have any thoughts on this? Whatever decision we make in this instance should probably apply to the other misplaced ABCs in collections.abc (e.g., should Callable go into functools somehow, into abc?). Yury Selivanov voted for putting them in abc directly since having to always try and find a proper module to put the abc might not always work, and so putting the concrete interface ABCs that directly define what Python's syntactic sugar and interpreter rely on made sense. Terry Reedy even suggested that collections.abc was a mistake and should have been made abc.collections (which wouldn't be hard due to how all the relevant code for collections.abc is in Lib/_collection_abc.py and hence already in an odd place). I'm a little partial to putting the ABCs in relevant modules like functools and contextlib, but otherwise I think abc makes sense.
I think putting the context manager ABC in contextlib is the right thing. However I detest functools and I really don't think Callable belongs there. It's been in collections.abc since it was introduced AFAIK, and it should just be grandfathered in. If I had to pick a better place for it I'd vote for (plain) abc, since that stores fundamental types. IMO Callable is a lot more fundamental than a context manager (even though both have direct interpreter support). On Thu, Dec 3, 2015 at 5:27 PM, Brett Cannon <brett@python.org> wrote:
In http://bugs.python.org/issue25609 I said I wanted an ABC for context managers and a matching entry in typing. I originally suggested putting it in collections.abc <https://docs.python.org/3/library/collections.abc.html> but Raymond Hettinger pointed out that it doesn't really belong there (along with a bunch of other ABCs like Callable and Awaitable).
So I opened http://bugs.python.org/issue25637 to discuss this, but I realize maybe this SIG is a better place to have a real discussion. The options I see are:
1. Ignore Raymond's objection and put it in collections.abc 2. Stick it in contextlib <https://docs.python.org/3/library/contextlib.html> 1. Directly 2. In a new contextlib.abc submodule 3. Stick in abc <https://docs.python.org/3/library/abc.html> 1. Directly 2. In some new subclass like abc.interfaces
Do people have any thoughts on this? Whatever decision we make in this instance should probably apply to the other misplaced ABCs in collections.abc (e.g., should Callable go into functools somehow, into abc?).
Yury Selivanov voted for putting them in abc directly since having to always try and find a proper module to put the abc might not always work, and so putting the concrete interface ABCs that directly define what Python's syntactic sugar and interpreter rely on made sense. Terry Reedy even suggested that collections.abc was a mistake and should have been made abc.collections (which wouldn't be hard due to how all the relevant code for collections.abc is in Lib/_collection_abc.py and hence already in an odd place).
I'm a little partial to putting the ABCs in relevant modules like functools and contextlib, but otherwise I think abc makes sense.
_______________________________________________ stdlib-sig mailing list stdlib-sig@python.org https://mail.python.org/mailman/listinfo/stdlib-sig
-- --Guido van Rossum (python.org/~guido)
participants (2)
-
Brett Cannon -
Guido van Rossum