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
