Greg Ewing wrote:
>
> "M.-A. Lemburg" <mal@lemburg.com>:
>
> > I'm not sure I can follow you here: DictType.__repr__ is the
> > representation method of the dictionary and not inherited
> > from TypeType, so there should be no problem.
>
> The problem is that DictType.__repr__ could mean either
> the unbound method for finding the repr of a dictionary,
> or the bound method for finding the repr of DictType
> itself.
>
> This ambiguity is inherent in the Python language as soon
> as you try to make classes into instances (which you have
> to do as a consequence of making types into classes).
We are actually trying to turn classes into types here :-)
Really, I think that we could resolve this issue by not inheriting
from meta-classes. DictType is a creation of the meta-class
TypeType. I'm not calling these instances to prevent additional
confusion. The root of the problem is that for some reason there
is belief that DictType should implicitly inherit attributes and
methods from TypeType. If we simply say that there is no implicit
inheritance (only explicit one), then these problems should go
away.
Some of these ideas are burried in the "super" part of this
thread. Unfortunately this concept doesn't go very far since
Python has multiple inheritance and thus the term "super"
(referring to the class' single base class) is not well-defined.
As Jim mentioned in his reply to Thomas' question, SmallTalk
has two parallel hierarchies. One for the classes and one for
the meta-classes. If we follow the same path in Python and
keep the two well separated, I think we can resolve many of
the issues which are currently showing up.
To link the two hierarchies together we don't need a "super"
concept, but instead a way to reach the meta-class in charge
of a class, say "klass.__creator__".
Note that there's another issue hiding in all this and again
this is due to multiple inheritance: which meta-class is in
charge of a class which is derived from two classes having
different meta-classes ?
meta1 --> o klass1
o klass1a
o klass1b
meta2 --> o klass2
o klass2a
o klass2b
class klass3(klass1a, klass2b):
...
I think there's no clean way to resolve this, so I'd suggest
to simply rule this out and declare it illegal (class can
only be based on classes having the same meta-class).
--
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting: http://www.egenix.com/
Python Software: http://www.lemburg.com/python/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4