> [marc w]
> Yes, I think that would be a good idea anyway.
It's been unenthusiastically argued both ways in the past; apparently
hasn't been a _real_ problem for anyone, so "ain't broke, don't fix" has
carried the day. By now I bet too much code depends on it to change it.
So a new name would be in order. BTW, it's easy to write these kinds of
things _in_ Python.
> ... let type (use any other name, if old code relies on the "ignorant"
> current behaviour) always return the class object of which the object
> is an instance.
The devil's in the details: then what does "type2" return when fed a
class object? "type2(C) is type2(C())" is no improvement <wink>.
> Adding some support for testing whether some class is a (direct or
> indirect) subclass of another probably wouldn't hurt.
This gets batted around unenthusiastically from time to time too; also
easy to write in Python (if C is a class, C.__bases__ is a (possibly
empty) tuple of its base classes; recursive search).
> It might be useful to introduce a whole reflective meta-object-
> protocol (it wouldn't be necessary, but open yet another can of worms
> ;-)
I'm against that, because I'd have to learn what the words mean <0.9
grin>.
> Assuming the above functionality was there, the "pseudo-multi-method"
> definition might look as simple as:
>
> class Vector: # maybe just an abstract superclass
> # ...
>
> def scalar__mul__vector(s, v): # ordinary function, no method
> # ... # maybe using only abstract methods
>
> # a useful abbreviation, probably defined in some central place
> builtin_numeric_types = [type(1), type(1L), type(1.1)]
>
> # define a handler; a sequence of types is like one call for each element;
> # subclasses inherit definitions unless they register more specific ones;
> operator.def_mul(builtin_numeric_types, type(vector), scalar__mul__vector)
I've never used a language with multi-methods, so have no feel for how
they'd work out in practice. From your sketch, the basic idea is clear,
and certainly has attractions! It's especially nice that it would get
rid of the disguised case statements in the implementations of things
like Vector classes. BTW, your "builtin_numeric_types" creation has an
analogue in Python's exception system, where exceptions can be grouped
into named tuples (which can themselves be nested, and ...), and an
"except Tuple:" statement does a deep search for the current exception in
Tuple. So that part's a comfortable fit already.
OTOH, it's unclear that it's a Good Thing to separate the implementation
from the class body. But it is a Good Thing that it forces consideration
of cases that are too easy to overlook if it all works by magic; e.g.,
suppose class A and class B are registered but class C isn't, and C
inherits from A and B? I.e., not clear what happens to a call involving
a C object (error? treated like an A? or a B? why or why not etc).
Off-the-wall observation: All the interfaces above can be coded in
Python today. Then e.g. everyone could write their __mul__ methods as:
def __mul__(x,y):
return operator.invoke_mul(x,y)
Seriously, one of the reasons Grand Changes don't often get into Python
is because it's so easy to fake them. It would take a real change to the
language to get multi-methods to work for the special methods, but you
could fake it for non-special functions now (BTW, a couple months ago Jim
Roskind posted a nice piece on various ways to fake function overloading
today, well worthing digging out of the archives if it interests you).
> Just another idea, about the other syntax questions (aka flame wars):
> Why not define a standard abstract syntax tree, with which everyone's
> favoured tools could play around? [and description of nice things you
> can do with ASTs]
Well, because it's easier to make a good suggestion than to implement it,
just as it's easier to ask a question than to listen to an answer <smile>.
> Just playing around with possibilities ... <heritic-grin>
Marc, you're not a heretic! Speaking as a self-appointed Python Bishop,
I hereby proclaim that your heart is in The Right Place, and you have my
imprimatur.
that-and-two-bucks-will-get-you-a-cup-of-coffee-ly y'rs - tim
Tim Peters tim@ksr.com
not speaking for Kendall Square Research Corp