[Python-Dev] type categories
Michael McLay
mclay@nist.gov
Tue, 13 Aug 2002 15:45:29 -0400
On Tuesday 13 August 2002 02:02 pm, Andrew Koenig wrote:
[...]
> I'm uneasy about (4) because if an object is an iterator, calling its
> next() method is destructive. The implication is that you had better
> not use this method to test if an object is an iterator until you are
> ready to take irrevocable action based on that test.
The test would be non-destructive if the test only checks for the existence of
the next() method.
hasattr(f,"next")
> Here is what I realized this morning. It may be obvious to you,
> but it wasn't to me (until after I realized it, of course):
>
> ``iterator'' and ``iterable'' are just two of many type
> categories that exist in Python.
>
> Some other categories:
>
> callable
> sequence
> generator
> class
> instance
> type
> number
> integer
> floating-point number
> complex number
> mutable
> tuple
> mapping
> method
> built-in
>
> As far as I know, there is no uniform method of determining into which
> category or categories a particular object falls. Of course, there
> are non-uniform ways of doing so, but in general, those ways are, um,
> nonuniform. Therefore, if you want to check whether an object is in
> one of these categories, you haven't necessarily learned much about
> how to check if it is in a different one of these categories.
>
> So what I wonder is this: Has there been much thought about making
> these type categories more explicitly part of the type system?
The category names look like general purpose interface names. The addition of
interfaces has been discussed quite a bit. While many people are interested
in having interfaces added to Python, there are many design issues that will
have to be resolved before it happens. Hopefully the removal of the
class/type wart and the use of interfaces in Zope will hasten the addition of
interfaces.
I like your list of the basic Python interfaces. Perhaps a weak version of
interface definitions could be added to Python prior to a full featured
capability. The weak version would simply add a __category__ attribute to the
each type definition. This attribute would reference an object that defines
the distinguishing features of the category interface. Enforcement would be
optional, but at least the definition would be published. Adding just the
definition of the type interface would create a direct benefit, but it would
provide a hook for developers to use in work on optimization and testing.