Really stupid question regarding PEP 252 and type/class unification

[Marcin 'Qrczak' Kowalczyk]

22 Aug 2001 12:44:18 -0700, Russell Turpin <russell_turpin at hotmail.com> pisze:

>     spam = 3
> 
> The variable "spam" is an Integer, "Integer" is now a class
> (unification, right?), so there should be *some* attribute
> of the class Integer, lets call it __myval__, such that:
> 
>     spam.__myval__ == 3

Why?

In designing an "everything is a [...]" type of framework (e.g.
everything is an object, or a function) there must be a place where
the ideal abstract recursive structure of the world breaks somehow.
There must be a way to insert some concrete. Perhaps not easily
reachable from inside, i.e. the world pretends that everything looks
the same, but...

If *every* object would be for example a dictionary from strings to
objects plus a reference to an object (its class), then you wouldn't
be able to do anything with it. You can't call any of its methods:
you can extract it, you have a "callable" in hand, but if it's an
object like others, then you perhaps need to extract its __call__
entry, and call it - well, this means getting *its* __call__ entry
etc. ad infinitum.

Or if you want to add two numbers you could call a method of the first
passing it the second as argument. The method code would examine the
second number, but even if it could figure out that it's an integer
too, it must somehow get its value. If it meant extraction of a
__myval__ entry, then what is found at __myval__? Perhaps an integer,
so to get its bits you will look at its __myval__ etc.?

The abstract knot can be broken in various places. For example by
introducing primitive object types. Or by introducing functions which
return something other than regular objects. Or by not pretending that
every object is defined by its __dict__ and having primitive functions
(where calling a function is done differently than by getting some of
its official attributes) which are able to perform operations on some
objects whose behavior is not visible in their __dict__.

Or something similar. But having a dictionary of attributes as the
*only* possible interface of objects just doesn't work.

I'm playing with similar ideas now. In the world I created every
identifier is bound to a function, a function takes functions as
arguments, but it doesn't return mere functions: there are other
kinds of values possible in function results as well, e.g. terms
and integers.

-- 
 __("<  Marcin Kowalczyk * qrczak at knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZASTĘPCZA
QRCZAK