function v. method

[danielx]

Bruno Desthuilliers wrote:
> danielx wrote:
> > Bruno Desthuilliers wrote:
> >
> >>danielx wrote:
>
> (snip)
> >>>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.
>
> !-)
>
> Ok, so now you have to read about descriptors, __getattribute__ and
> __setattr__.
>
> >
> >>>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.
>
> Indeed.
>
> > 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.
>
> ...and source code...

*shudders* What happened to all the goodness of abstraction?

>
> > 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.
>
> Single leading underscore means "implementation, don't touch or you're
> on your own".

I'll remember that. I had forgotten what the convention was for
labeling things "do not touch".

>
>
> --
> bruno desthuilliers
> python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
> p in 'onurb at xiludom.gro'.split('@')])"