|
|
|
|
|
|
| Author |
Message |
bruno modulix
*nix forums Guru
Joined: 21 Feb 2005
Posts: 819
|
 Posted: Fri Jul 21, 2006 12:22 pm Post subject:
Re: function v. method
|
|
|
Antoon Pardon wrote:
| Quote: | On 2006-07-21, fuzzylollipop <jarrod.roberson@gmail.com> wrote:
danielx wrote:
(snip)
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.
|
To bad for you.
| Quote: | It isn't clear enough.
|
Oh yes ?
| Quote: | 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.
|
Either you imported with the "from othermodule import *" form (which you
shouldn't do), and you *don't* have the implementation of othermodule,
or your used the "import othermodule" form, in which case it's pretty
obvious which names belongs to othermodule.
Have any other, possibly valid, reason ?
| Quote: | And I find variable starting or ending with an underscore ugly. 
|
Too bad for you. Choose another language then... PHP, Perl, Ruby ?-)
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])" |
|
| Back to top |
|
 |
Antoon Pardon
*nix forums Guru
Joined: 21 Feb 2005
Posts: 483
|
| Posted: Fri Jul 21, 2006 10:47 am Post subject:
Re: function v. method
|
|
|
On 2006-07-21, fuzzylollipop <jarrod.roberson@gmail.com> wrote:
| Quote: |
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 |
|
| Back to top |
|
|
bruno modulix
*nix forums Guru
Joined: 21 Feb 2005
Posts: 819
|
| Posted: Fri Jul 21, 2006 8:49 am Post subject:
Re: function v. method
|
|
|
danielx wrote:
| Quote: | Bruno Desthuilliers wrote:
danielx wrote:
(snip)
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?
|
Compared to machine language, Python source code is really abstration.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])" |
|
| Back to top |
|
|
Diez B. Roggisch
*nix forums Guru
Joined: 20 Feb 2005
Posts: 882
|
|
| Back to top |
|
|
Alex Martelli
*nix forums Guru
Joined: 19 Feb 2005
Posts: 955
|
| Posted: Fri Jul 21, 2006 5:30 am Post subject:
Re: function v. method
|
|
|
danielx <danielwong@berkeley.edu> wrote:
| Quote: | ...and source code...
*shudders* What happened to all the goodness of abstraction?
|
<http://www.joelonsoftware.com/articles/LeakyAbstractions.htm>
Alex |
|
| Back to top |
|
|
fuzzylollipop
*nix forums beginner
Joined: 15 Apr 2005
Posts: 36
|
| Posted: Fri Jul 21, 2006 2:23 am Post subject:
Re: function v. method
|
|
|
danielx wrote:
| Quote: | 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.
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. |
|
| Back to top |
|
|
danielx
*nix forums beginner
Joined: 18 Jul 2006
Posts: 8
|
| Posted: Thu Jul 20, 2006 9:10 pm Post subject:
Re: function v. method
|
|
|
Bruno Desthuilliers wrote:
| Quote: | 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?
| Quote: |
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".
| Quote: |
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])" |
|
|
| Back to top |
|
|
bruno modulix
*nix forums Guru
Joined: 21 Feb 2005
Posts: 819
|
| Posted: Thu Jul 20, 2006 8:52 am Post subject:
Re: function v. method
|
|
|
danielx wrote:
| Quote: | Bruno Desthuilliers wrote:
danielx wrote:
|
(snip)
| Quote: | 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__.
| Quote: |
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.
| Quote: | 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...
| Quote: | 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".
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])" |
|
| Back to top |
|
|
danielx
*nix forums beginner
Joined: 18 Jul 2006
Posts: 8
|
| Posted: Thu Jul 20, 2006 1:57 am Post subject:
Re: function v. method
|
|
|
Duncan Booth wrote:
| Quote: | danielx wrote:
Foo.func = dan # <-- Appearantly, something magical happens here,
because...
Foo.func
unbound method Foo.dan
f = Foo.func
f is dan # <-- things begins to look suprising here.
False
ismethod(f)
True
Imagine my surprise. Why would Python do this?
Nothing magical happens at the point you said. The assignment is just an
assignment and you saw that the function was stored unchanged when you
looked in the class's dictionary.
The magic happens when you access a member of a class or an instance. If
the value is a descriptor then its __get__ method is called. Roughly
speaking, Foo.func is equivalent to:
Foo.__dict__['func'].__get__(None, Foo)
unbound method Foo.dan
Python does this so that it can support other descriptor types such as
property, classmethod, staticmethod.
You can see this happening if you define your own descriptor:
class MyDesc(object):
def __get__(self, *args):
print "__get__ called", args
return None
d = MyDesc()
Foo.oops = d
Foo.oops
__get__ called (None, <class __main__.Foo at 0x00B3F930>)
http://docs.python.org/ref/descriptor-invocation.html has a description of
this. Although it claims "Note that descriptors are only invoked for new
style objects or classes (ones that subclass object() or type())." the
descriptor mechanism is partially implemented for old style classes.
Several aspects of descriptors don't work properly though in old-style
classes which is one reason why you should always use new-style classes.
Privates don't have to be entirely absent from Klass.__dict__
(which would make Python not introspective); they can just be invisible
when using the dot-syntax.
You could implement that using a data descriptor, but if you are going to
prevent access to your private variables using the dot operator, then your
code is going to look pretty silly with a lot of references to
self.__dict__['theprivate'] which doesn't gain anything in readability over
self.__theprivate.
|
I believe you are talking about the same thing as Leif, but I can't
quite tell. I'll need to read your paper as well  . |
|
| Back to top |
|
|
danielx
*nix forums beginner
Joined: 18 Jul 2006
Posts: 8
|
| Posted: Thu Jul 20, 2006 1:54 am Post subject:
Re: function v. method
|
|
|
Leif K-Brooks wrote:
| Quote: | danielx wrote:
This is still a little bit of magic, which gets me thinking again about
the stuff I self-censored. Since the dot syntax does something special
and unexpected in my case, why not use some more dot-magic to implement
privates? Privates don't have to be entirely absent from Klass.__dict__
(which would make Python not introspective); they can just be invisible
when using the dot-syntax.
You can do this now, kind of:
class Foo(object):
... x = property()
... def doStuffWithX(self):
... self.__dict__['x'] = 123
... print self.__dict__['x']
...
bar = Foo()
bar.doStuffWithX()
123
bar.x
Traceback (most recent call last):
File "<stdin>", line 1, in ?
AttributeError: unreadable attribute
If you're proposing that self.x and bar.x should give different results,
then that's quite a bit more magic than property() and methods use. They
|
Yes, I had not considered that very carefully...
Let me finish reading that before I get back to your point. |
|
| Back to top |
|
|
danielx
*nix forums beginner
Joined: 18 Jul 2006
Posts: 8
|
| Posted: Thu Jul 20, 2006 1:43 am Post subject:
Re: function v. method
|
|
|
Bruno Desthuilliers wrote:
| Quote: | 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.
| Quote: |
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.
| Quote: |
(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@xiludom.gro'.split('@')])" |
|
|
| Back to top |
|
|
bruno modulix
*nix forums Guru
Joined: 21 Feb 2005
Posts: 819
|
| Posted: Tue Jul 18, 2006 8:38 am Post subject:
Re: function v. method
|
|
|
danielx wrote:
| Quote: | 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".
| Quote: | 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 ?
| Quote: | why not use some more dot-magic to implement
privates?
|
What for ? What makes you think we need language-inforced access
restriction ?
(snip)
| Quote: | 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@xiludom.gro'.split('@')])" |
|
| Back to top |
|
|
Duncan Booth
*nix forums Guru
Joined: 11 Mar 2005
Posts: 422
|
| Posted: Tue Jul 18, 2006 7:42 am Post subject:
Re: function v. method
|
|
|
danielx wrote:
| Quote: | Foo.func = dan # <-- Appearantly, something magical happens here,
because...
Foo.func
unbound method Foo.dan
f = Foo.func
f is dan # <-- things begins to look suprising here.
False
ismethod(f)
True
Imagine my surprise. Why would Python do this?
|
Nothing magical happens at the point you said. The assignment is just an
assignment and you saw that the function was stored unchanged when you
looked in the class's dictionary.
The magic happens when you access a member of a class or an instance. If
the value is a descriptor then its __get__ method is called. Roughly
speaking, Foo.func is equivalent to:
| Quote: | Foo.__dict__['func'].__get__(None, Foo)
unbound method Foo.dan |
Python does this so that it can support other descriptor types such as
property, classmethod, staticmethod.
You can see this happening if you define your own descriptor:
| Quote: | class MyDesc(object):
def __get__(self, *args): |
print "__get__ called", args
return None
| Quote: | d = MyDesc()
Foo.oops = d
Foo.oops
__get__ called (None, <class __main__.Foo at 0x00B3F930>) |
http://docs.python.org/ref/descriptor-invocation.html has a description of
this. Although it claims "Note that descriptors are only invoked for new
style objects or classes (ones that subclass object() or type())." the
descriptor mechanism is partially implemented for old style classes.
Several aspects of descriptors don't work properly though in old-style
classes which is one reason why you should always use new-style classes.
| Quote: | Privates don't have to be entirely absent from Klass.__dict__
(which would make Python not introspective); they can just be invisible
when using the dot-syntax.
|
You could implement that using a data descriptor, but if you are going to
prevent access to your private variables using the dot operator, then your
code is going to look pretty silly with a lot of references to
self.__dict__['theprivate'] which doesn't gain anything in readability over
self.__theprivate. |
|
| Back to top |
|
|
Leif K-Brooks
*nix forums Guru Wannabe
Joined: 22 Feb 2005
Posts: 132
|
| Posted: Tue Jul 18, 2006 7:31 am Post subject:
Re: function v. method
|
|
|
danielx wrote:
| Quote: | This is still a little bit of magic, which gets me thinking again about
the stuff I self-censored. Since the dot syntax does something special
and unexpected in my case, why not use some more dot-magic to implement
privates? Privates don't have to be entirely absent from Klass.__dict__
(which would make Python not introspective); they can just be invisible
when using the dot-syntax.
|
You can do this now, kind of:
| Quote: | class Foo(object):
.... x = property() |
.... def doStuffWithX(self):
.... self.__dict__['x'] = 123
.... print self.__dict__['x']
....
| Quote: | bar = Foo()
bar.doStuffWithX()
123
bar.x
Traceback (most recent call last): |
File "<stdin>", line 1, in ?
AttributeError: unreadable attribute
If you're proposing that self.x and bar.x should give different results,
then that's quite a bit more magic than property() and methods use. They
both use the descriptor API; for more information on that, read
<http://python.org/download/releases/2.2.3/descrintro/>. |
|
| Back to top |
|
|
bayerj
*nix forums beginner
Joined: 02 Apr 2006
Posts: 12
|
| Posted: Tue Jul 18, 2006 6:19 am Post subject:
Re: function v. method
|
|
|
I guess the python devs are not interested in implementing something
that would require new syntax and does not give something entirely new
to the language.
The good thing about python is, that the devs are only implementing
ideas that are very cool. There are a lot of cool (!= very cool) ideas
in rejected peps - but they were never implemented for good reasons.
If you *really* need privates, just use the naming convention. |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Sat Nov 22, 2008 12:08 am | All times are GMT
|
|
Best Credit Cards | Debt | Unsecured Loans | Paper Models | Remortgages
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
Programming
»
python
