Attack a sacred Python Cow

Bruno Desthuilliers bdesth.quelquechose at free.quelquepart.fr
Thu Jul 24 17:04:50 CEST 2008


Torsten Bronger a écrit :
> Hallöchen!
> 
> Bruno Desthuilliers writes:
> 
>> Torsten Bronger a écrit :
>>
>>> Bruno Desthuilliers writes:
>>>
>>>> [...]
>>>>
>>>> How would you handle this case with an implicit 'self' :
>>>>
>>>> class Foo(object):
>>>>    pass
>>>>
>>>> def bar(self):
>>>>    print self
>>>>
>>>> Foo.bar = bar
>>> Just like this.  However, the compiler could add "self" to
>>> non-decorated methods which are defined within "class".
>> What's defined within classes are plain functions. It's actually
>> the lookup mechanism that wraps them into methods (and manage to
>> insert the current instance as first argument).
> 
> And why does this make the implicit insertion of "self" difficult?

Did I say such a thing ?

Call me pedantic if you want, but I find it easier to understand how 
something works when using the appropriate terms, that's all.

> I could easily write a preprocessor which does it after all.

A source-code-preprocessor based solution wouldn't do IMHO. But that was 
not the point. The point is that a working solution would require to 
handle "functions-or-else" defined within a class statement as a special 
case, which obviously makes thing more compl[ex|icated]. Now as far as 
I'm concerned, as long as such a solution 1/ doesn't impose any 
restriction wrt/ current features of Python's object model and 2/ 
doesn't make any of the currently used "metaprogramming" idioms more 
difficult, I just wouldn't care.






More information about the Python-list mailing list