[Python-Dev] Organization of ABC modules

Nick Coghlan ncoghlan at gmail.com
Sat Jan 26 06:31:49 CET 2008


Raymond Hettinger wrote:
>> If you want ABCs to be more easily recognizable
>> as such, perhaps we could use a naming convention, 
> 
> Essentially, that's all I was asking for.  It doesn't
> really matter to me whether numbers.py gets called
> abc_numbers or abc.numbers.  Either one would be an
> improvement.

I think the module level is the wrong granularity to be thinking about 
this - look at a module like collections, which contains not only ABC's 
related to containers, but also some useful concrete containers like 
deque and namedtuple.

Any naming convention would have to be at the class level. For example:

class NumberABC(metaclass=ABCMeta):
    ...

class ComplexABC(NumberABC):
    ...

class RealABC(ComplexABC):
    ...

class RationalABC(NumberABC):
    ...

class IntegralABC(RationalABC):
    ...

I think adopting such a convention (at least for the standard library) 
would actually be useful. Normally, finding isinstance() type checks in 
code bothers me severely as it usually indicates that duck-typing has 
been broken. On the other hand, if I find a check in code that does 
something like:

   if not isinstance(x, NumberABC):
      raise TypeError("Not a number!")

it would clearly still be extensible, as I would know just from the 
naming convention that a third party can register their type with 
NumberABC to make it usable with this function.

Without a naming convention, I would always have to go check the 
definition of the type in the isinstance() call to see if the code was 
legitimate.

Cheers,
Nick.


-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org


More information about the Python-Dev mailing list