Python 3K or Python 2.9?

Bruno Desthuilliers bdesth.quelquechose at free.quelquepart.fr
Sun Sep 16 15:12:04 EDT 2007


John Roth a écrit :
> On Sep 12, 11:35 am, TheFlyingDutchman <zzbba... at aol.com> wrote:
> 
>>On Sep 12, 4:40 am, Bjoern Schliessmann <usenet-mail-0306.20.chr0n... at spamgourmet.com> wrote:
>>
>>>Ivan Voras wrote:
>>>
>>>>What does "self" have to do with an object model? It's an
>>>>function/method argument that might as well be hidden in the
>>>>compiler without ever touching the role it has (if not, why?). I
>>>>agree that it's needless noise in a language.
>>
>>>If this was needless, why do C++ and Java have the "this" pointer?
>>
>>"this" in C++ and Java is not shown in the parameter list, which was
>>what he was
>>complaining about.  He wants
>>
>>class MyClass:
>>        def SomeFunction(someParameter):
>>           self.someParameter = someParameter
>>
>>not
>>
>>class MyClass:
>>        def SomeFunction(self, someParameter):
>>           self.someParameter = someParameter
>>
>>The confusing way about the current Python method when you first
>>encounter it is
>> why is "self" being passed in when you write the function but not
>>when you call it. If the compiler is smart enough to know that
>>
>>    a = MyClass()
>>    a.SomeFunction(12)
>>
>>SomeFunction() has a "self" implicitly added to the parameter list, it
>>seems that it should be smart enough to know that a function defined
>>in a class has a "self" implicitly added to the parameter list.
> 
> 
> Pretty close. This is one of the things that's always puzzled me about
> the discussion. Making self and cls keyword pseudo-constants that get
> the current instance and class from the stack frame (or raise an
> exception) would eliminate them from the method header.

I suppose that by header, you mean prototype or signature. But anyway, 
it's not a *method* signature, it's a *function* signature - and the 
compiler persists to have nothing to do with all this...

> It would ALSO eliminate a whole level of indirection in method
> invocation and get rid of the instancemethod, classmethod and
> staticmethod wrapper classes. This would be a significant
> simplification. If it had been done earlier, it would have eliminated
> most of the justification for method attributes (those silly @
> things), 

"those silly @ things" has *nothing* to do with methods nor with 
attributes. It's just syntactic sugar for HOFs. Period.

> thus showing that unneeded complexity breeds more unneeded
> complexity.

John, there are plenty of other OOPls around that don't requires neither 
explicit use of the instance/class reference nor mention of it in the 
function . If after having read this whole thread and all relevant 
documentation, you still don't understand why Python works that way and 
why most of us are *totally* happy with the way it works, I strongly 
suggest that you switch to another language. Not that I have nothing 
personal against you, but it should be quite clear that this part of 
Python is not going to change - FWIW, as Alex pointed out, I doubt even 
GvR could impose such a change now.



More information about the Python-list mailing list