[Python-Dev] type categories

[Michael McLay]

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.