[issue25637] Move non-collections-related ABCs out of collections.abc

Guido van Rossum added the comment: Honestly I think this such a slippery slope that I prefer keeping them in collections.abc. The main reason that we have Iterable and Iterator is that they are closely related to real collections (e.g. Sequence, Set, Mapping). And generators are related to

[issue25637] Move non-collections-related ABCs out of collections.abc

Brett Cannon added the comment: So leave Callable and Coroutine there and if I add a context manager ABC put it in collections.abc as well? Or should we put Callable and Coroutine in functools and a context manager one in contextlib (or Coroutine in asyncio)? --

[issue25637] Move non-collections-related ABCs out of collections.abc

Guido van Rossum added the comment: I think ContextManager should be in contextlib. I don't want to put anything in functools. Coroutine doesn't belong in asyncio, it's more fundamental (closely related to Generator). -- ___ Python tracker

[issue25637] Move non-collections-related ABCs out of collections.abc

Brett Cannon added the comment: Thanks for the input everyone! -- resolution: -> wont fix status: open -> closed ___ Python tracker ___

[issue25637] Move non-collections-related ABCs out of collections.abc

Yury Selivanov added the comment: > Did anyone consider moving these near the “types” module, either directly > inside, or as a “types.abc” submodule? In my mind, these ABCs would fit > reasonably well there. They are related to built-in types, but do not have > built-in names. Big -1.

[issue25637] Move non-collections-related ABCs out of collections.abc

Martin Panter added the comment: Did anyone consider moving these near the “types” module, either directly inside, or as a “types.abc” submodule? In my mind, these ABCs would fit reasonably well there. They are related to built-in types, but do not have built-in names. -- nosy:

[issue25637] Move non-collections-related ABCs out of collections.abc

Nick Coghlan added the comment: >From a documentation perspective, I'd suggest breaking the ABC module >documentation at https://docs.python.org/3/library/abc.html into three >subsections: 29.7.1 Defining Abstract Base Classes This would include the existing docs for ABC, ABCMeta,

[issue25637] Move non-collections-related ABCs out of collections.abc

Changes by Nick Coghlan : -- nosy: +ncoghlan ___ Python tracker ___ ___ Python-bugs-list

[issue25637] Move non-collections-related ABCs out of collections.abc

Terry J. Reedy added the comment: I would not like to have, say, 20 namespaces, some with just one ABD, such as functools.abc.Callable. I might have preferred abc.collections to collections.abc, etc. -- nosy: +terry.reedy ___ Python tracker

[issue25637] Move non-collections-related ABCs out of collections.abc

Yury Selivanov added the comment: > I guess is the objection of putting concrete ABCs in the abc module is that > the abc module contains the actual code to implement ABCs and not ABCs > themselves. I think it's a rather weak objection. Having some basic (and fundamental!) ABCs defined

[issue25637] Move non-collections-related ABCs out of collections.abc

Changes by Ezio Melotti : -- nosy: +ezio.melotti ___ Python tracker ___ ___

[issue25637] Move non-collections-related ABCs out of collections.abc

Yury Selivanov added the comment: We had this discussion when we were adding Awaitable, AsyncIterable etc. I suggested to simply put them in the top-level 'abc' module (where ABCMeta is defined). -- nosy: +yselivanov ___ Python tracker

[issue25637] Move non-collections-related ABCs out of collections.abc

Brett Cannon added the comment: I guess is the objection of putting concrete ABCs in the abc module is that the abc module contains the actual code to implement ABCs and not ABCs themselves. Personally I would be fine with a submodule within abc like abc.interfaces. Personally I'm starting to

[issue25637] Move non-collections-related ABCs out of collections.abc

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