Confused with methods

Diez B. Roggisch deetsNOSPAM at web.de
Wed Feb 9 05:18:36 EST 2005


> It doesn't. As Alex has already explained, the above is equivallent to:
> 
> def h(): pass
> 
> class A:
>   l = []
>   f = h
> 
> a = A()
> print a.l is A.l
> print a.f is A.f

So what - the difference is between bound and unbound method, which is what
were talking here about after all - so in the end, its a question of how a
bound method gets created. I'm pretty sure there are plenty of other ways
to create one - try the new module, metaclasses and what not. But that they
exist and are different from unbound methods or functions is not
inconsistent. In the same spirit you could call instance methods in
languages like java or c++ inconsistent - as the have an implicit first
argument, which "normal" functions don't have. So either way round - its a
bit of magic for having oo-style method dispatch. If you want to get rid of
it, don't use OO or at least don't use classes. Nobody prevents you from
doing that.

 
> If I told you that this detail, well not this particular one but
> one that is close to it, will break one of my applications in
> the transition from python 2.3 to 2.4, do you still think
> it is irrelevant?

If its not _this_ detail, its not relevant for _this_ thread. And a general
assertion that transitional changes between versions of python create
problems might be worth a discussion - but that's not what were talking
about here. Instead, we're talking about inconsistencies in _one_ certain
version of python - inconsistencies that no one except you seems to
perceive.

> 
> I would also argue that if a particular detail is a stumbling block
> for someone to understand something it is not that irrelevant
> and that claiming something is inconsistent while it is not,
> is not a good way to remove such a stumbling block.

The OP very well understood the difference between bound and unbound
methods. His confusion was that there was no general currying mechanism
behind it that would create subsequent argument bindings if he stuffed a
method into another class. He now understands better.
> This did bother someone, it was a stumbling block for him understanding
> what was going on.

It did bother him because he didn't understand it in the first place - and
he now does understand it.

Well, I'm well prepared to agree to disagree with you on this. If you feel
its inconsistent, I'm not trying to convince you otherwise. But as I said
before: Even if it _is_ - its still of no practical impact. Also the OP
didn't have any further problems after seeing whats getting on. So lets
move along.

-- 
Regards,

Diez B. Roggisch



More information about the Python-list mailing list