[Python-Dev] Type checks of instance variables

[Michael McLay]

On Wednesday 10 October 2001 10:47 pm, Greg Ward wrote:
> Grouch works by parsing type descriptions (currently found in class
> docstrings) and creating an ObjectSchema instance.  An object schema
> consists of:

Extending the magic of __slots__  was intended to provide a minimally 
intrusive and pythonic solution to adding type verification to Python.  
Parsing docstrings to get the type definitions is a pragmatic work-around, 
but the features of Grouch would benefit by giving them direct language 
support.

>   * a collection of atomic types (default: int, long, float, complex,
>     string); all other types in the schema are built from these
>   * a collection of type aliases (eg. "number" could be an alias for
>     "int | float | long", or "FooBar" for "mypkg.foobar.FooBar")
>   * a collection of ClassDefinition objects
>
> A class definition, in turn, consists (mainly) of a list of instance
> attributes and the type of each instance attribute.

That's what the TypedSlots class does, so I think we are on the same page 
regarding what features are needed. 

> One of the things you can do with an object schema is use it to walk an
> object graph, enforcing the attribute types in the class definitions in
> the schema.  The two scripts currently distributed with Grouch do just
> that: gen_schema parses docstrings, creates an ObjectSchema, and pickles
> it; check_data loads the pickled schema, and uses it to typecheck some
> stored object graph (currently either another pickle or a ZODB).

Are you walking the object graph to enforce the type because it isn't 
possible to enforce them at creation time in the current Python language?  
The TypedSlots concept never allows the instance variables to be populated 
with anything but the allowed types.  

Adding this concept would have been difficult prior to the addition of 
__slots__ because it won't require changes that restrict access to the 
__dict__ of an object.  The proposed TypedSlots will require some changes to 
the C code that implements the __slots__ interpretation.  The interpretation 
of the __slots__ definition would be determined by the type of the __slot__ 
value.  If a list type is detected the interpreter would follow Guido's 
existing semantics.  If the value is a TypedSlots type the interpreter would 
enforce type checking.  The features of the Grouch schema will be helpful in 
shaping the definition of the type checking actions.
>
> The major things missing from Grouch right now are:
>   * simple value constraints (eg. "notnone", "notempty")
>   * fancy value constraints (eg. "oneof")
>   * any knowledge of new-style classes, eg. the __slots__ attribute

The primary advantage of __slots__ in Python is a reduction in memory usage.  
The TypedSlots extension is also an efficiency feature.  It would simplify 
the process of accessing the value of slots that are expected to be of a 
particular type and it may facilitate optimizations based on variable type 
information.   The TypedSlots mechanism would only apply to the variables 
defined with the new __slots__  mechanism.  Would this the constraint be a 
problem for the types of applications you are building with Grouch?