This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author brett.cannon
Recipients brett.cannon, rhettinger, stutzbach
Date 2015-11-16.19:21:22
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1447701682.74.0.653642972551.issue25637@psf.upfronthosting.co.za>
In-reply-to
Content
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?).
History
Date User Action Args
2015-11-16 19:21:22brett.cannonsetrecipients: + brett.cannon, rhettinger, stutzbach
2015-11-16 19:21:22brett.cannonsetmessageid: <1447701682.74.0.653642972551.issue25637@psf.upfronthosting.co.za>
2015-11-16 19:21:22brett.cannonlinkissue25637 messages
2015-11-16 19:21:22brett.cannoncreate