[Python-Dev] Organization of ABC modules

[Guido van Rossum]

On Jan 25, 2008 3:15 PM, Raymond Hettinger <python at rcn.com> wrote:
> All of the abstract base classes should be collected in one place.  I propose that the modules be collected into a package so that we can write:
>
>    import abc.numbers
>    import abc.collections
>     . . .
>
> Besides collecting all the relevant code in one place, it has a nice additional benefit of clearly designating when you're working with one of the provided abstract base classes.  When I see "import numbers", I don't immediately recognize this as being somehow different from "import math" or some other concrete implementation.
>
> IMO. the emerging practice of spreading modules these across the library isn't serving us well.

 I don't think so. Things should be grouped by application area, not
by some property like "uses metaclasses" or "defines abstract base
classes" or "overrides operators". The old types module collected all
"built-in types" and it was a mistake. You  might as well propose that
all decorators should live in the same package, or all generic
functions (if we ever have them). There's a lot more synergy between
the collection ABCs and other collections than between collection ABCs
and number ABCs.

Another angle: the io.py module also uses ABCs. Should it therefore be
a subpackage of ABC? No way!

If you want ABCs to be more easily recognizable as such, perhaps we
could use a naming convention, though personally I think we don't need
that either -- the generic names like "Sequence" or "Real" are enough
of a tip-off that these are type categories and not implementation
types.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)