Phillip J. Eby wrote: > At 12:58 PM 4/13/2006 -0700, Michael Chermside <[EMAIL PROTECTED]> wrote: > >>To be abundantly specific, the proposal is that if the next two tokens >>after a "def" were "self" and "." then the result of compiling such >>code would be exactly the same as if they were not present but "self" >>and "," were inserted immediately after the opening parenthesis. >>Whether to allow any identifier or only the particular identifier >>"self" is an interesting question that I would leave for Guido. >> >>Personally, I favor doing this. I think that making declarations look >>similar to invocations is very useful. > > > You could make them look even closer if it worked like this: > > def .aMethod(arg1, arg2): > return .otherMethod(arg1*2+arg2)
When talking about a method people often use ".method()", not just "method()", to distinguish a method-on-some-object (which from the outside can't be called "self") from a function. This syncs with that. OTOH, while the definition doesn't bother me, ".otherMethod(arg1*2+arg2)" looks pretty scary to me. Anyway, both this and "def self.aMethod(...)" solve the problems of an implicit argument by making the method-like nature of the function explicit. More explicit than currently, really, since currently the method-like nature is only inferred through a convention of naming the first argument "self". If we commit to the name "self" being more than mere convention, then "def .aMethod()" could really cause "self" to be bound. > In other words, 'self' here is uniformly replaced by an empty string. :) > > Interestingly, I believe this syntax could get everybody off our backs > about explicit self, as although it is still explicit, it's in an implicit > way. :) > > Of course, for this to really work properly, you would have to be able to > use a bare '.' to mean the hidden argument, for cases like "getattr(.,foo)" > and ".[27]". But "." is just *so* small. At least @ is sufficiently large that you can't visually miss it. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ 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
