On 2006-07-21, fuzzylollipop <[EMAIL PROTECTED]> 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!
Personnaly I don't like this convention. It isn't clear enough.
Suppose I am writing my own module, I use an underscore, to
mark variables which are an implementation detail for my
module.
Now I need to import an other module in my module and need access
to an implementation variable from that module. So now I have
variables with an underscore which have two different meanings:
1) This is an implemantation detail of this module, It is the
users of my module who have to be extra carefull using it.
2) This is an implemantation detail of the other module,
I should be extra carefull using it.
And I find variable starting or ending with an underscore ugly. :-)
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
