On Thu, Dec 31, 2015 at 12:48 PM Brett Cannon <brett@python.org> wrote:

On Thu, Dec 31, 2015, 07:08 Alexander Walters <tritium-list@sdamon.com> wrote:
Would it be a good idea to mix 'concrete implementations of ABCs'*
directly in the abc module where the tooling to create ABCs live, or to
put it in a submodule?  I feel it should be a submodule, but that isn't
based on vast experience.

Locating collections ABCs in a submodule makes some sense, as there are 21 of them and the collections module is important for beginners to learn without getting distracted by ABCs. Contrast that with the direct inclusion of ABCs in most other modules and it suggests the creation of a submodule for collections may have been motivated for the same reason as this discussion -- it didn't feel right to have certain ABCs directly in the collections module.

If the non-collection ABCs are being moved out of the collections module and into the ``abc`` module, there's less reason to separate them into a submodule. Beginners don't venture into the abc module expecting to understand everything. It's natural to find a bunch of ABCs in a module called ``abc``. And ABCs are included directly in many other modules instead of being relegated to a less discoverable submodule like ``typing.abc``, ``io.abc``, ``numbers.abc``, etc. as many of those are focused on ABCs in the first place.

It's easy to notice a submodule when reading docs on the internet, but it's hard to figure out what the correct module is to import when hanging out at a basic REPL. Flat is better than nested and all that.

* Yes, I know, these are not concrete implementations of types... I find
it a little confusing to describe.

It's a possibility. Feel free to comment on the issue if you want to discuss this further.