New submission from Brett Cannon: In discussing adding a context manager ABC in issue #25609, the idea of creating a new module for ABCs that is more analogous to the types modules came up. Currently all ABCs that are generic in the stdlib and don't belong to a specific module end up in collections.abc, e.g. the Awaitable ABC has nothing to do with data structures and yet it's in a module in the collections package.
What we could do is create an interfaces module which contains all the ABCs that are not specific to a package. This would mean moving the ABCs out of collections.abc that have nothing to do with collections such as things for async, etc. The real question, though, is how to decide what belongs where, e.g. is Iterable/Iterator a collection, and if so then what about Generator? The other option is that instead of introducing a generic interfaces module we simply create appropriate new modules to house the thematic ABCs and avoid a dumping ground scenario, e.g. some new module for the async stuff instead of just dumping them in an interfaces module. All the other ABCs could probably find existing homes, e.g. Callable could go into functools (although do we want to start a practice of having an abc submodule for all instances where ABCs exist and thus introduce functools.abc?). ---------- components: Library (Lib) messages: 254744 nosy: brett.cannon, rhettinger, stutzbach priority: normal severity: normal stage: test needed status: open title: Move non-collections-related ABCs out of collections.abc type: enhancement versions: Python 3.6 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25637> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
