Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > The type/object distinction and possible synthesis of OOP andimperative programming languages

Reply
Thread Tools

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

 
 
Mark Janssen
Guest
Posts: n/a
 
      04-15-2013
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. 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. The parser, lexer, and
such spin these abstrations into something that can be run on the
actual hardware.

As a contrast, this is very distinct from C++, where everything is
concretely rooted in the language's type model which in *itself* is
rooted (from it's long history) in the CPU architecture. The STL,
for example, has many Container types, but each of them requires using
a single concrete type for homogenous containers or uses machine
pointers to hold arbitrary items in heterogeneous containers (caveat:
I haven't programmed in C++ for a long time, so it's possible this
might not be correct anymore).

My question is: Is there something in the Computer Science literature
that has noticed this distinction/development in programming language
design and history?

It's very significant to me, because as languages went higher and
higher to this pure OOP model, the programmer+data ecosystem tended
towards very personal object hierarchies because now the hardware no
longer formed a common basis of interaction (note also, OOPs promise
of re-usable code never materialized).

It's not unlike LISP, where the power of its general language
architecture tended towards hyperpersonal mini macro languages --
making it hardly used, in practice, though it was and is so powerful,
in theory.

That all being said, the thrust of this whole effort is to possibly
advance Computer Science and language design, because in-between the
purely concrete "object" architecture of the imperative programming
languages and the purely abstract object architecture of
object-oriented programming languages is a possible middle ground that
could unite them all.

Thank you for your time.

Mark Janssen
Tacoma, Washington
 
Reply With Quote
 
 
 
 
Steven D'Aprano
Guest
Posts: n/a
 
      04-15-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
 
Reply With Quote
 
 
 
 
Antoon Pardon
Guest
Posts: n/a
 
      04-15-2013
Op 15-04-13 12:11, Steven D'Aprano schreef:

>
> 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.


I had gotten my hopes up after reading this but then I tried:


$ python3
Python 3.2.3 (default, Feb 20 2013, 17:02:41)
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class vslice (slice):

.... pass
....
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: type 'slice' is not an acceptable base type


It seems types and classes are still not mere synonyms.
 
Reply With Quote
 
Dave Angel
Guest
Posts: n/a
 
      04-15-2013
On 04/15/2013 01:43 PM, Antoon Pardon wrote:
> Op 15-04-13 12:11, Steven D'Aprano schreef:
>
>>
>> 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.

>
> I had gotten my hopes up after reading this but then I tried:
>
>
> $ python3
> Python 3.2.3 (default, Feb 20 2013, 17:02:41)
> [GCC 4.7.2] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> class vslice (slice):

> ... pass
> ...
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> TypeError: type 'slice' is not an acceptable base type
>
>
> It seems types and classes are still not mere synonyms.


No, it seems you're trying to use an internal detail as though it were a
supported feature.

From page:
http://docs.python.org/3.3/reference...del.html#types

"""Internal types
A few types used internally by the interpreter are exposed to the user.
Their definitions may change with future versions of the interpreter,
but they are mentioned here for completeness.
"""


--
DaveA
 
Reply With Quote
 
Rotwang
Guest
Posts: n/a
 
      04-15-2013
On 15/04/2013 22:13, Dave Angel wrote:
> On 04/15/2013 01:43 PM, Antoon Pardon wrote:
>> [...]
>>
>> I had gotten my hopes up after reading this but then I tried:
>>
>>
>> $ python3
>> Python 3.2.3 (default, Feb 20 2013, 17:02:41)
>> [GCC 4.7.2] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> class vslice (slice):

>> ... pass
>> ...
>> Traceback (most recent call last):
>> File "<stdin>", line 1, in <module>
>> TypeError: type 'slice' is not an acceptable base type
>>
>>
>> It seems types and classes are still not mere synonyms.

>
> No, it seems you're trying to use an internal detail as though it were a
> supported feature.
>
> From page:
> http://docs.python.org/3.3/reference...del.html#types
>
> """Internal types
> A few types used internally by the interpreter are exposed to the user.
> Their definitions may change with future versions of the interpreter,
> but they are mentioned here for completeness.
> """


To be fair, one can't do this either:

Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:57:17) [MSC v.1600 64
bit (AMD64)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> class C(type(lambda: None)):

pass

Traceback (most recent call last):
File "<pyshell#2>", line 1, in <module>
class C(type(lambda: None)):
TypeError: type 'function' is not an acceptable base type


and I don't think that FunctionType would be considered an "internal
detail", would it? Not that I'd cite the fact that not all types can be
inherited from as evidence that types and classes are not synonyms, mind.
 
Reply With Quote
 
Chris Angelico
Guest
Posts: n/a
 
      04-15-2013
On Tue, Apr 16, 2013 at 8:12 AM, Rotwang <(E-Mail Removed)> wrote:
> Traceback (most recent call last):
> File "<pyshell#2>", line 1, in <module>
> class C(type(lambda: None)):
> TypeError: type 'function' is not an acceptable base type
>
>
> and I don't think that FunctionType would be considered an "internal
> detail", would it? Not that I'd cite the fact that not all types can be
> inherited from as evidence that types and classes are not synonyms, mind.


Actually, I'm not sure how you'd go about inheriting from a function.
Why not just create a bare class, then assign its __call__ to be the
function you're inheriting from?

ChrisA
 
Reply With Quote
 
Rotwang
Guest
Posts: n/a
 
      04-15-2013
On 15/04/2013 23:32, Chris Angelico wrote:
> On Tue, Apr 16, 2013 at 8:12 AM, Rotwang <(E-Mail Removed)> wrote:
>> Traceback (most recent call last):
>> File "<pyshell#2>", line 1, in <module>
>> class C(type(lambda: None)):
>> TypeError: type 'function' is not an acceptable base type
>>
>>
>> and I don't think that FunctionType would be considered an "internal
>> detail", would it? Not that I'd cite the fact that not all types can be
>> inherited from as evidence that types and classes are not synonyms, mind.

>
> Actually, I'm not sure how you'd go about inheriting from a function.
> Why not just create a bare class, then assign its __call__ to be the
> function you're inheriting from?


No idea. I wasn't suggesting that trying to inherit from FunctionType
was a sensible thing to do; I was merely pointing out that slice's
status as an internal feature was not IMO relevant to the point that
Antoon was making.
 
Reply With Quote
 
Terry Jan Reedy
Guest
Posts: n/a
 
      04-16-2013
On 4/15/2013 1:43 PM, Antoon Pardon wrote:

> $ python3
> Python 3.2.3 (default, Feb 20 2013, 17:02:41)
> [GCC 4.7.2] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> class vslice (slice):

> ... pass
> ...
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> TypeError: type 'slice' is not an acceptable base type
>
>
> It seems types and classes are still not mere synonyms.


Some builtin classes cannot be subclassed. There is an issue to document
which better. That does not mean that it is not a class.


 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      04-16-2013
On Mon, 15 Apr 2013 19:43:32 +0200, Antoon Pardon wrote:

> Op 15-04-13 12:11, Steven D'Aprano schreef:
>
>
>> 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.

>
> I had gotten my hopes up after reading this but then I tried:
>
>
> $ python3
> Python 3.2.3 (default, Feb 20 2013, 17:02:41) [GCC 4.7.2] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> class vslice (slice):

> ... pass
> ...
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> TypeError: type 'slice' is not an acceptable base type
>
>
> It seems types and classes are still not mere synonyms.



You are misinterpreting what you are reading. The mere fact that
something cannot be subclassed doesn't mean anything. That's just a
restriction put on the class by the implementation. It's not even clear
that it is a guaranteed language restriction or a mere accident of
implementation. With a bit of metaclass trickery, I could equally create
a pure-Python class that cannot be easily subclassed.

The proof that types and classes are the same in Python 3 is simple:

py> class C:
.... pass
....
py> type(C) is type(int) is type(type) is type
True

The type of the pure-Python class is type itself.

However, even this can be bypassed, using a metaclass!

py> class D(metaclass=Meta):
.... pass
....
py> type(D) is type
False
py> issubclass(type(D), type)
True


So when using a metaclass, the type of the class is not necessarily type
itself, but it will be a subclass of type.

This does not hold in Python 2.x, not for old-style "classic" classes.
Classic classes are in a world of their own, distinct from types:

# Python 2
py> class C:
.... pass
....
py> type(C)
<type 'classobj'>
py> issubclass(type(C), type)
False



In Python 3, we can expect these two conditions to always hold:

* all instances are instances of object;

* all classes are instances of type.


Notice that this implies that type and object are circularly defined:
object, being a class, is an instance of type, but type, being an object,
is an instance of object:

py> isinstance(type, object)
True
py> isinstance(object, type)
True



These two conditions even apply to unsubclassable objects like slice:

py> isinstance(slice(1, 5, 2), object)
True
py> isinstance(slice, type)
True



--
Steven
 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      04-16-2013
On Mon, 15 Apr 2013 20:52:58 -0400, Terry Jan Reedy wrote:

> On 4/15/2013 1:43 PM, Antoon Pardon wrote:
>
>> $ python3
>> Python 3.2.3 (default, Feb 20 2013, 17:02:41) [GCC 4.7.2] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> class vslice (slice):

>> ... pass
>> ...
>> Traceback (most recent call last):
>> File "<stdin>", line 1, in <module>
>> TypeError: type 'slice' is not an acceptable base type
>>
>>
>> It seems types and classes are still not mere synonyms.

>
> Some builtin classes cannot be subclassed. There is an issue to document
> which better. That does not mean that it is not a class.



I think it is also important to document whether that is a language
feature, or a mere restriction of the implementation. There is an
important distinction to be made between:

"In CPython, you cannot subclass slice or FunctionType. Other Pythons may
have more, or fewer, restrictions."

and:

"No language that calls itself Python is permitted to allow slice and
FunctionType to be subclassable."


If I had a say in this, I would vote for the first case, with the
possible exception of documented singleton types like NoneType and bool.



--
Steven
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Windows 8 - so bad it's hastening the death of the PC? ~misfit~ NZ Computing 18 04-15-2013 04:15 AM
Byters? Since the distinction between interpreters and compilers seems to be hazy sometimes, has anybody proposed a third distinction? Casey Hawthorne Java 4 10-20-2005 03:29 PM
List and tuple usage distinction?? Ishwar Rattan Python 2 09-02-2004 01:12 AM
what are the possible reasons that successful pre-synthesis simulation + successful synthesis = failed post-synthes walala VHDL 4 09-08-2003 01:51 PM
Distinction between a method and a member function Tim Martin C++ 20 09-05-2003 01:52 AM



Advertisments