On 4/12/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 4/12/06, Tim Hochberg <[EMAIL PROTECTED]> wrote: > > What would happen if 'a+b' was just syntactic sugar for > > 'operator.add(a,b)', where operator.add was a generic > > function, instead of the current magic dance involving > > __add__ and __radd__.
Conceptually, I had already thought of it that way in existing python, and had to spend a few days thinking about why it isn't quite true. As I see it, (1) Returning NotImplemented is a clumsier way of restricting the signature for which you want to register. (2) The leftovers of coerce are arguably extra, but could certainly be part of the generic default. (3) 3rd parties could register new add signatures; the equivalent of modifying __add__ and __radd__ methods. Only number (3) is really a change, and realistically, it would be a (cleaner) version of letting you monkeypatch even builtins. Now that Guido is thinking about it ... > What if, instead of adding registries mapping types to functions left > and right (in pickle, copy, pprint, who knows where else), we had a > convention of adding __foo_bar__ methods directly to the class dict? If you can only add (not replace), then the first user wins. If you can replace, that is a gaping security issue when someone replaces part of dict. (Which would be a quite reasonable thing to do, for debugging or read-only proxies, or ...) -jJ _______________________________________________ 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
