[Python-Dev] Type checks of instance variables (original) (raw)

Michael McLay mclay@nist.gov
Thu, 11 Oct 2001 13:20:19 -0400

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: genschema parses docstrings, creates an ObjectSchema, and pickles it; checkdata 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?