Really stupid question regarding PEP 252 and type/class unification

[Marcin 'Qrczak' Kowalczyk]

23 Aug 2001 07:07:02 -0700, Russell Turpin <russell_turpin at hotmail.com> pisze:

> What's a little bothersome about 252 is that types are *almost*
> classes, except (among other things) their instances carry around
> this extra information that can be reached *only* by their unadorned
> name.

I'm afraid that this question is not well defined.

Consider the behavior of a function. It can be reached by __call__
attribute. But f.__call__ is almost equivalent to f, so this
almost-self-reference didn't help in exposing contents. We could
as well define that x.__self__ is x for all objects x, and now *no*
information can be reached *only* by unadorned name!

Imagine that strings don't have method __len__ and their length may
be obtained only by len(). Does it count? If not, what do you mean
by "unadorned name" - that information must be available through
attribute access?

Consider a string of length 1. Are its contents exposed? You can
use s[0] to get its character, but it gives back the same string,
so it's the same case as hypothetical x.__self__. You can use ord(),
but it's like len() above. Do you consider string contents exposed?

> The question, in this kind of endeavor, is: "How do you 
> ground the uniform, recursive rule in the simplest way 
> possible, i.e., without introducing too many new rules for
> the ground objects?"

Indeed. IMHO the simplicity of overall rules is what can be weighted.

> Yeah, and that's what really bothers me. At the end of the
> day, I want the Python type model to be so simple that I can 
> write its rules on a single page. Type and class unification
> *should* be a step toward that, not just a way to add more 
> features.

I want this too and I'm afraid that it's too hard now, quite impossible
with these constraints. Especially if backward compatibility is
involved: old and new rules together, and rules kept probably only
for compatibility (e.g. attaching information to exceptions in
various ways).

It's not clear to what extent the library counts. Does moving things
from core language to the library make the language simpler? On
one hand the overall ease of use doesn't need to change at all: the
same amount of concepts remain. On the other hand libraries may be
generally ignored when they are not used, and core language features
are not so well self-contained and their use is more implicit (bound
methods are created without a distinguished syntax).


> So here are some questions. Suppose I derive a class from
> a base type:
> 
>     class MyInt(type(0)):
>         pass
> 
>     myInt = MyInt()
>     myInt = 5                     # Will this work? 

Of course these bindings are independent. This works too:
    myInt = 5
    myInt = "spam"

> Now I type "myInt" into the interpreter. Does it print out:
> 
>     5
> 
> Or does it print:
> 
>     <instance of MyInt>

5. I tested it with dictionary, which can be derived in Python-2.2a1.
I expected this - the __str__ method is inherited.

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