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   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org
_______________________________________________
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

Reply via email to