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