function v. method

[danielx]

fuzzylollipop wrote:
> danielx wrote:
> > 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.
> >
>
>
> if you prefix with a single underscore, that tells the user, DON'T MESS
> WITH ME FROM OUTSIDE! I AM AN IMPLEMENTATION DETAIL!
>
> and it gets ommited from all the doc generation
>
> if you prefix with a double underscore, then they have to go even
> FARTHER out of their way to shoot themselves in the foot.
>
> Python takes the stance of "personal responsiblity" when it comes to
> access control. Which in NO WAY dimishes its "robustness" or anything
> else.
>
> just read the DailyWTF.com, incompentent people will abuse any language
> features in any language, and will figure out how to break programatic
> access control no matter how it is implemented. Matter of fact, Java
> which in another thread someone was ADAMANT that did not expose private
> anything from reflection ( and was wrong ) specifically allows you to
> access all the private members, functions, everything. You just need to
> tell it to turn all the "safeties" off.
>
> >From the api:
>
> public void setAccessible(boolean flag)
> throws SecurityException
>
> Set the accessible flag for this object to the indicated boolean value.
> A value of true indicates that the reflected object should suppress
> Java language access checking when it is used. A value of false
> indicates that the reflected object should enforce Java language access
> checks.
>
> Setting the accessible flag in a reflected object permits sophisticated
> applications with sufficient privilege, such as Java Object
> Serialization or other persistence mechanisms, to manipulate objects in
> a manner that would normally be prohibited.
>
> so anything added to Python to enforce "access control" would
> immediately be forced to provide some means to over-ride the checks for
> pickle and the like. Not to even mention the argument that it would
> break crap loads of existing code base.

Sigh. I TOTALLY realize that Python works by politeness and not
enforcement. I think you are misinterpreting why I think this would be
a good idea. My concern is not with control, but with convenience. My
suggestion was that privates would only be invisible if you use the dot
syntax (ie if you are an external user); they would not be invisible
altogether (they would still be in __dict__ with no name games).

One problem which was brought up about this was that self.meth and
outsider.meth would have to be interpretted differently. I suspect (but
I haven't finished my reading assignment :P) that you could find a good
way around this.

With respect to breaking stuff. I'm not sure why that would be
necessary. If current code does not say any member is private,
everything that was visible before (ie everything) would still be
visible after.

Last thing. You mentioned that auto doc generation omits
underscore-prefixed and name mangled members. dir on the other hand
does not. Maybe this suggests only a minor future improvement.