On 11/25/06, Calvin Spealman <[EMAIL PROTECTED]> wrote: > 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.
Do you realize that expr[expr::expr] already has a meaning? You seem to be doing an exceptionally poor job explaining your proposal; you are introducing a new token "::" without ever explaining what you propose it should mean. How does operator::len differ from operator.len? > > 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/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ 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
