On 11/22/06, Calvin Spealman <[EMAIL PROTECTED]> wrote: > This whole thing seems a bit off from start to finish. A seperate > definition syntax with a special name/expression weirdo thingy, etc.
I have the same gut feelings but find it hard to explain why. But I've learned to trust my gut -- eventually it will come to me. Perhaps it's okay for the operation definitions to be outside the class for which they apply? That at least clarifies that their *invocation* also doesn't involve method notation. > Anyway, we need something that handles this but isnt specific to this. > There are other situations it may be useful. Essentially we want to > have names that are known to be in some namespace, even within > another. Does that make sense? > > Perhaps we could allow a special type of key in __dict__'s (and > __slots__'s ?) that was more than a simple string name but included a > namespace or context in which the name was to be understood. Even a > simple 2-tuple would be enough. (operator, 'len') might be the entry > for a method that the len builtin called, for example. A simple syntax > would preceed the . operator to create names with this convention, > maybe even using the familiar :: from other languages. > > class myclass(object): > def operator::len(self): > return self.length > ... > > Very simple, can have more uses than the single, limited use case > being discussed. Not sure I like this better. My spelling of "operator::XXX" is "__XXX__" and I like that just fine -- no new syntax needed. -- --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
