About the Abstract classes

[edreamleo]

This discussion is pre-writing for one section of the Theory of Operation. See #660.

Overview of the Abstract classes

There are three Abstract classes: AbstractClass, AbstractFunction, and AbstractModule.

Notation: Let AbstractX (or just Abstract) denote one of these three classes.

Rope's inference code contains many tests of the form if isinstance(obj, AbstractX):

The primary purpose of the Abstract classes is to make these tests.

In other words, the Abstract classes "mark" classes as the base of Rope's type hierarchy. See the next section.

The Abstract classes do three things:

1. The Abstract classes make a class a subclasses of the PyObject class.
2. The Abstract classes override a few methods. In effect, these methods become part of the PyObject class.
3. The Abstract classes help init the PyObject class: The Abstract classes have ctors of the form:

def __init__(self):
     super().__init__(get_base_type("X"))

where X is Module, or Function, but Type instead of Class. Why? Because in Python the type of a class (not an instance) is type:

class MyClass:
    pass
    
print(type(MyClass))

prints <class 'type'>.

The Data model chapter of the Python language manual provides a wealth of gory details, which happily we can mostly ignore.

The 9 subclasses of AbstractX

Let b and po denote Rope's builtins and pyobjects modules respectively.

Rope's codebase defines 9 subclasses of the three Abstract classes:

• 2 subclasses of AbstractModule: po._PyModule and b.BuiltinModule.
• 4 subclasses of AbstractClass: po.PyClass, b.BuiltinClass, b.Generator, and b.Iterator.
• 3 subclasses of AbstractFunction: po.PyFunction, b.BuiltinFunction, and b.Lambda.

Summary

Abstract classes mark 9 other classes as the base of the Rope's type hierarchy.

There are other ways of marking these classes, but exactly these 9 classes must be marked somehow.

Tests of the form if isinstance(obj, AbstractX) are True if obj (a PyObject) is a base of Rope's type hierarchy.

[edreamleo]

P.S. Writing documentation (and PRs, docstrings, and discussions) arguably takes more work than writing code.

Richard Dawkins describes writing as an evolutionary process, which is apt coming from him. I have found that remark helpful. I don't expect to create great writing in one go any more than I expect to write perfect code the first time! More importantly, it's fun to see writing take shape—to see evolution in action.

I much prefer having too much writing to work with at first. I can then revise (evolve) what I have. But it's hard to revise writing that doesn't exist.

[edreamleo]

Hearing no corrections I am going to close this discussion. It no longer proposes any code changes.

I don't remember why I said the deleted words, but they no longer apply. This discussion is a prelude to a PR that would simplify Rope's class structure.