I will make only one more comment and then ill drop my comments without direct questions.
On 11/25/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > Hm. The double colon rubs me the wrong way (Perl and/or C++). But > apart from that, if this is the solution, I'm not sure the problem > you're trying to solve is really worth solving. I just don't expect > there will be all that many generic operations that need to be stuffed > into arbitrary classes. Maybe I'll just take back what I said about > wanting all such operations to be inside the class. Or maybe I'd be > happier if there was a decorator indicating the name of the operation. I don't care about the syntax. anything that can denote an expression (the left of the ::) and a name (the right of the ::) is OK and I dont care how its denoted. > Also, I think you're overloading 'def' in a non-obvious way. > Currently, "def foo..." means an assignment to the local variable foo. > I would expect that if we extend the syntax for the thing between > 'def' and the argument list to be more than just a name, it should > still be considered an assignment target. But that's clearly not what > you're after. From that POV, I find defop (while still unpleasant for > other reasons) more "honest" than your overloading of def -- at least > defop says upfront that it's not just an assignment. (Although the > similarity with def is still confusing IMO.) You must be misunderstanding me. I am not saying that its not an assignment. It would not change what def really means. operator::len would be the actual name of the function to be created and the name of the global, local, or class attribute it is bound to. I am saying operator::len would become something like MyClass.__dict__[operator::len] and what operator::len evaluates to, i dont know. something that represents what it is. Maybe just a tuple. I would expect it also exist for any assignment. special casing being bad and all. > Still not convinced? Focus on other problems first. This isn't the > most important problem we're trying to solve. > > PS, It's __builtin__, not __builtins__ -- the latter is an > unfortunately named but ultimately unimportant implementation detail > (unimportant unless you're implemented restricted python, that is); > the former is the module that is implied at the end of every free name > search. > > > --Guido -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.com/ _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
