On Jan 25, 2008 3:15 PM, Raymond Hettinger <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
