bruno at modulix wrote: > Technically, they are still function objects. They are later wrapped > into method descriptor objects (at lookup time IIRC, but ask a guru or > read the doc to know for sure). And don't forget the case of nested > functions...
I don't see how nested functions change anything. If they're nested in a method, they can access self, but the name mapping is done at runtime. Unless you mean a nested fucntion which is dynamically added as a method, but that's the same case as the next one. >> If you're declaring >> methods outside the class and adding them dynamically, I think you would >> need to declare 'self' explicitly. > > Of course. Virtually *any* function can be set as a method[1] outside > the class statement scope, either directly on the class object or - with > manual wrapping - on an individual instance. And it's important to keep > this feature. I wouldn't dream otherwise. >> Well I'm assuming the rules for when to put 'self' in the parameter list >> are simple enough to be automated. > > They are still complex enough to require a real parser. And anyway, > since this is a syntax change, this should be handled by the parser IMHO. I agree, but it's good to keep options in mind. > Honestly, I don't think it has much chance. I barely even notice typing > 'self' or 'cls', and I guess it's the same for most Python programmers > - those who can't stand it probably use another language... And FWIW, I > still prefer to keep consistency in functions definitions. I have no doubt that's true for a lot of people. Hell I probably prefer the current approach because 1) it's not a big deal in practice, and 2) I can use the shorter 'me' or 's' in place of self in my own code, which I couldn't do under the change (well, I could add 'me = self' as the first statement of any method, but that's clumsy). My objections stem more from an elegance standpoint. Of course elegance is in the eye of the beholder. -- http://mail.python.org/mailman/listinfo/python-list
