> I had thought that you (Bill), (along with PJE) were assuming that the > generic function or interface itself would serve to distinguish the > namespace. Instead of > > class A(object): > def magic_meth_foo(self, ...): > > I would write > > class A(object): > defop foo.magic_meth(self, ...) >
There seem to be two justifications for "special" methods that have been adduced (though I see no real justification for the name-mangling scheme). One is that they serve as a way of specifying which code operators and their cousins, the "built-in" generic functions, call. The other is that they somehow serve as connections to the underlying VM implementation. Now, I don't see why the connection to the underlying VM implementation needs name-mangling -- it would be reasonable just to define a distinguished module (call it, say, for tradition's sake, "__VM__" :-), and put them in that module. But there does need to be some way to connect operator syntax to code, and we could talk about how to do that. Defop is one solution; you could also imagine an ABC for each operator, and classes which wish to use that operator, or overload it, would inherit from that ABC and re-define the methods. The question is, would those methods, bound to specific operators, be so pervasive and so common that their logical method names would, if not mangled, occupy too much of the available naming space? Maybe. I think it's a judgement call. Bill _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
