function v. method

danielx danielwong at berkeley.edu
Wed Jul 19 21:43:24 EDT 2006


Bruno Desthuilliers wrote:
> danielx wrote:
> > At first I was going to post the following:
> >
> > <!-- beginning of my original post -->
> >
> (snip)
> >
> > <!-- end of my original post, with ending censored -->
> >
> > but then I tried this:
> >
> >
> >>>>res = Foo.__dict__['func']
> >>>>res is dan
> >
> > True
> >
> > And it all started to make sense. The surprising thing turned out to be
> > not so surprising: When the expression Foo.func gets evaluated, we get
> > a method which is just a wrapper around dan. Therefore, f is not dan!
> > This is still a little bit of magic,
>
> FWIW, the function class implements the descriptor protocol... Here's
> the "magic".
>
> > which gets me thinking again about
> > the stuff I self-censored. Since the dot syntax does something special
> > and unexpected in my case,
>
> "unexpected" ? Did you ever wondered how the instance or class was
> passed as first arg when doing method calls ?

Not knowing what's going on during method calls is exactly what
motivated me to post.

>
> > why not use some more dot-magic to implement
> > privates?
>
> What for ? What makes you think we need language-inforced access
> restriction ?

I knew someone would bring this up. The motivation would not be to
provide restriction, but to help maintain clean api's. If you intended
for users to use only a subset of the methods in your class, why not
help them learn your api by presenting the stuff they can use not along
side the stuff they should not?

Obviously, such things would be omitted from your docs, but users also
learn by interacting with Python, which is really one of Python's great
virtues. When supporting documents aren't sufficient to learn an api
(I'm sure this never happens, so just humor me), you can always turn to
interactive Python. This is exactly what it's there for. If nothing is
hidden, a user could be easily mislead to believe he can use a method
when he really shouldn't.

>
> (snip)
>
> > BTW, I am aware of Python's name mangling feature.
>
> Name mangling is mainly here to protect from accidental overridding. The
>  convention for implementation attributes is single-leading-underscore.
>
>
> --
> bruno desthuilliers
> python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
> p in 'onurb at xiludom.gro'.split('@')])"




More information about the Python-list mailing list