Yes, I think that would be a good idea anyway. I didn't look into the
implementation, but I doubt it would be extremely difficult (or slow)
to 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. Adding some support for testing whether some class is
a (direct or indirect) subclass of another probably wouldn't hurt. It
might be useful to introduce a whole reflective meta-opbject-protocol
(it wouldn't be necessary, but open yet another can of worms ;-)
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)
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? One function would parse the normal
syntax into the standard AST, another would compile the AST into byte
codes, and if someone wants a more Ada-like or more Lisp-Like syntax,
they would be free to use a frontend for that (and a Lisp-like syntax
could certainly be trivially generated by code generators, if a text-
interface is preferred over embedding a generator in Python to create
the AST directly).
Just playing around with possibilities ... <heritic-grin>
------------------------------------------------------------------------------
* wonder everyday * nothing in particular * all is special *
Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>