The type/object distinction and possible synthesis of OOP and imperative programming languages

Steven D'Aprano steve+comp.lang.python at pearwood.info
Mon Apr 15 06:11:14 EDT 2013


On Sun, 14 Apr 2013 20:48:05 -0700, Mark Janssen wrote:

> Hello,
> 
> I'm new to the list and hoping this might be the right place to
> introduce something that has provoked a bit of an argument in my
> programming community.
> 
> I'm from the Python programming community.  Python is an "interpreted"
> language.  Since 2001, Python's has migrated towards a "pure" Object
> model (ref: http://www.python.org/download/releases/2.2/descrintro/).
> Prior to then, it had both types and classes and these types were
> anchored to the underlying C code and the machine/hardware architecture
> itself.


Incorrect.

Python's data model has always been 100% object oriented. Prior to the 
"class/type" unification, it simply had *two distinct* implementations of 
objects: types, which were written in C, and classes, which were written 
in Python.

After unification, the two kinds of object were no longer entirely 
distinct -- you could then subclass types in Python code, using the same 
"class" keyword as you would use for a pure-Python class.

And starting with Python 3, the last vestiges of the distinction have 
disappeared. Now, "class" and "type" are mere synonyms. Both built-in 
types and custom classes use the same mechanism.


> After the 2001 "type/class unification" , it went towards Alan
> Kay's ideal of "everything is an object".  From then, every user-defined
> class inherited from the abstract Object, rooted in nothing but a pure
> abstract ideal.

Incorrect. In Python 2.7:


py> class AClass:
...     pass
... 
py> issubclass(AClass, object)
False



-- 
Steven



More information about the Python-list mailing list