|
|
|
|
|
|
| Author |
Message |
Lawrence Oluyede
*nix forums addict
Joined: 20 Oct 2005
Posts: 61
|
 Posted: Mon Jul 10, 2006 12:24 pm Post subject:
Re: Accessors in Python (getters and setters)
|
|
|
mystilleef <mystilleef@gmail.com> wrote:
| Quote: | What is the Pythonic way of implementing getters and setters.
|
Using public members and turning them into properties when needed
| Quote: | I've
heard
people say the use of accessors is not Pythonic. But why?
|
Because there's no need to have them everywhere
| Quote: | But now my code base is expanding and I'm beginning to appreciate the
wisdom behind them. I welcome example code and illustrations.
|
Search for "python property"
--
Lawrence - http://www.oluyede.org/blog
"Nothing is more dangerous than an idea
if it's the only one you have" - E. A. Chartier |
|
| Back to top |
|
 |
Diez B. Roggisch
*nix forums Guru
Joined: 20 Feb 2005
Posts: 882
|
| Posted: Mon Jul 10, 2006 12:33 pm Post subject:
Re: Accessors in Python (getters and setters)
|
|
|
mystilleef wrote:
| Quote: | Hello,
What is the Pythonic way of implementing getters and setters. I've
heard
people say the use of accessors is not Pythonic. But why? And what is
the alternative? I refrain from using them because they smell
"Javaish."
But now my code base is expanding and I'm beginning to appreciate the
wisdom behind them. I welcome example code and illustrations.
|
Which wisdom do you mean? The wisdom that a language that has no property
mechanism and thus can't intercept setting and getting of instance members
needs a bulky convention called JAVA Beans, so that _all_ uses of
properties are tunneled through some code, even if only a few percent of
these actually need that?
Or the wisdom that strangling developers by putting access modifiers with
approx. a dozen different rules in place is an annoyance to adult
developers to say the least?
These are the reasons they are not pythonic. We can intercept property
access (see the property descriptor, http://pyref.infogami.com/property),
and we trust in developers being able to judge form themselves if messing
with internals of code is a good idea or not.
Regards,
Diez |
|
| Back to top |
|
|
mystilleef@gmail.com
*nix forums beginner
Joined: 11 Oct 2005
Posts: 46
|
| Posted: Mon Jul 10, 2006 12:51 pm Post subject:
Re: Accessors in Python (getters and setters)
|
|
|
I decided to change the name of an attribute. Problem is I've used the
attribute in several places spanning thousands of lines of code. If I
had encapsulated the attribute via an accessor, I wouldn't need to do
an unreliable and tedious search and replace accross several source
code files to achieve my goal. I could simply change the name of the
attribute and move on. Well, I'm glad python has properties. It's a
feature that should be advertised more, especially for large scale
python development.
Diez B. Roggisch wrote:
| Quote: | mystilleef wrote:
Hello,
What is the Pythonic way of implementing getters and setters. I've
heard
people say the use of accessors is not Pythonic. But why? And what is
the alternative? I refrain from using them because they smell
"Javaish."
But now my code base is expanding and I'm beginning to appreciate the
wisdom behind them. I welcome example code and illustrations.
Which wisdom do you mean? The wisdom that a language that has no property
mechanism and thus can't intercept setting and getting of instance members
needs a bulky convention called JAVA Beans, so that _all_ uses of
properties are tunneled through some code, even if only a few percent of
these actually need that?
Or the wisdom that strangling developers by putting access modifiers with
approx. a dozen different rules in place is an annoyance to adult
developers to say the least?
These are the reasons they are not pythonic. We can intercept property
access (see the property descriptor, http://pyref.infogami.com/property),
and we trust in developers being able to judge form themselves if messing
with internals of code is a good idea or not.
Regards,
Diez |
|
|
| Back to top |
|
|
antroy@gmail.com
*nix forums addict
Joined: 24 May 2006
Posts: 52
|
| Posted: Mon Jul 10, 2006 1:12 pm Post subject:
Re: Accessors in Python (getters and setters)
|
|
|
mystilleef wrote:
| Quote: | I decided to change the name of an attribute. Problem is I've used the
attribute in several places spanning thousands of lines of code. If I
had encapsulated the attribute via an accessor, I wouldn't need to do
an unreliable and tedious search and replace accross several source
code files to achieve my goal. I could simply change the name of the
attribute and move on.
|
You could, but then you'd be left with crap names for your accessors!
In your equivalent Java code, you'd typically have used the accessors
in several places throughout the code (or else why bother using them?),
so you wouldn't be any better off!
The main benefit for having accessors in Java is not that you can
change the *name* of an attribute, but that you can change the
implementation of the attribute - i.e. change the what actually happens
to when the accessor is called. Which you can do in Python with
properties. |
|
| Back to top |
|
|
Diez B. Roggisch
*nix forums Guru
Joined: 20 Feb 2005
Posts: 882
|
| Posted: Mon Jul 10, 2006 2:19 pm Post subject:
Re: Accessors in Python (getters and setters)
|
|
|
mystilleef wrote:
| Quote: | I decided to change the name of an attribute. Problem is I've used the
attribute in several places spanning thousands of lines of code. If I
had encapsulated the attribute via an accessor, I wouldn't need to do
an unreliable and tedious search and replace accross several source
code files to achieve my goal. I could simply change the name of the
attribute and move on. Well, I'm glad python has properties. It's a
feature that should be advertised more, especially for large scale
python development.
|
Ergh, I don't see how the name-changing of an attribute makes any difference
with respect to the application of getters/setters.
Where is the difference in searching my_attribute vs. getMyAttribute
throughout your code?
Or do you mean that you changed
def getFoo(self):
return self.foo
to something like
def getFoo(self):
return self.fooSomething
? I'd say that whatever reasoning which inspired you to change foo to
fooSomething applies to getFoo as well.
Regards,
Diez |
|
| Back to top |
|
|
bruno modulix
*nix forums Guru
Joined: 21 Feb 2005
Posts: 819
|
| Posted: Mon Jul 10, 2006 3:35 pm Post subject:
Re: Accessors in Python (getters and setters)
|
|
|
mystilleef wrote:
| Quote: | I decided to change the name of an attribute. Problem is I've used the
attribute in several places spanning thousands of lines of code. If I
had encapsulated the attribute via an accessor, I wouldn't need to do
an unreliable and tedious search and replace
|
find and grep are usually mostly reliable for this kind of tasks.
| Quote: | accross several source
code files to achieve my goal. I could simply change the name of the
attribute and move on.
|
Why did you change the name of the attribute ? If it was to better
reflect the semantic, then it's a change in the API and getters/setters
wouldn't have help (you'd have to do the same "tedious and unreliable"
search/replace dance). If it's about implementation, then it was time to
use a property - that's what they are for.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])" |
|
| Back to top |
|
|
Jason
*nix forums Guru Wannabe
Joined: 02 Mar 2005
Posts: 189
|
| Posted: Mon Jul 10, 2006 3:55 pm Post subject:
Re: Accessors in Python (getters and setters)
|
|
|
mystilleef wrote:
| Quote: | I decided to change the name of an attribute. Problem is I've used the
attribute in several places spanning thousands of lines of code. If I
had encapsulated the attribute via an accessor, I wouldn't need to do
an unreliable and tedious search and replace accross several source
code files to achieve my goal. I could simply change the name of the
attribute and move on. Well, I'm glad python has properties. It's a
feature that should be advertised more, especially for large scale
python development.
Diez B. Roggisch wrote:
mystilleef wrote:
Hello,
What is the Pythonic way of implementing getters and setters. I've
heard
people say the use of accessors is not Pythonic. But why? And what is
the alternative? I refrain from using them because they smell
"Javaish."
But now my code base is expanding and I'm beginning to appreciate the
wisdom behind them. I welcome example code and illustrations.
Which wisdom do you mean? The wisdom that a language that has no property
mechanism and thus can't intercept setting and getting of instance members
needs a bulky convention called JAVA Beans, so that _all_ uses of
properties are tunneled through some code, even if only a few percent of
these actually need that?
Or the wisdom that strangling developers by putting access modifiers with
approx. a dozen different rules in place is an annoyance to adult
developers to say the least?
These are the reasons they are not pythonic. We can intercept property
access (see the property descriptor, http://pyref.infogami.com/property),
and we trust in developers being able to judge form themselves if messing
with internals of code is a good idea or not.
Regards,
Diez
|
The property() mechanism gets rid of the need for getters and setters,
as you can invisibly change a member variable into a getter/setter as
needed. Nothing else needs to know that its using a property and not a
getter/setter.
Nothing like being forced to write getters and setters in C++/Java
before you feel like shooting your source code. Please don't bring
this code-rage into Python.
To refactor a name in your code, take a look at Bicycle Repair Man
[http://bicyclerepair.sourceforge.net/]. It integrates into Eclipse
via PyDev, and allows you to refactor variable names, class names, and
method names fairly easily.
Good luck!
--Jason |
|
| Back to top |
|
|
ZeD
*nix forums beginner
Joined: 27 Dec 2005
Posts: 6
|
| Posted: Tue Jul 11, 2006 6:07 am Post subject:
Re: Accessors in Python (getters and setters)
|
|
|
Bruno Desthuilliers wrote:
| Quote: | I decided to change the name of an attribute. Problem is I've used the
attribute in several places spanning thousands of lines of code. If I
had encapsulated the attribute via an accessor, I wouldn't need to do
an unreliable and tedious search and replace
find and grep are usually mostly reliable for this kind of tasks.
|
you mean sed :)
sed 's/oldName/newName/g' oldFile > newFile
--
Under construction |
|
| Back to top |
|
|
bruno modulix
*nix forums Guru
Joined: 21 Feb 2005
Posts: 819
|
| Posted: Tue Jul 11, 2006 8:15 am Post subject:
Re: Accessors in Python (getters and setters)
|
|
|
ZeD wrote:
| Quote: | Bruno Desthuilliers wrote:
I decided to change the name of an attribute. Problem is I've used the
attribute in several places spanning thousands of lines of code. If I
had encapsulated the attribute via an accessor, I wouldn't need to do
an unreliable and tedious search and replace
find and grep are usually mostly reliable for this kind of tasks.
you mean sed 
|
No, I meant find and grep.
| Quote: | sed 's/oldName/newName/g' oldFile > newFile
Yeah, fine - as long as your pretty sure the same name is not used in |
other contexts in any of the source files...
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])" |
|
| Back to top |
|
|
mystilleef@gmail.com
*nix forums beginner
Joined: 11 Oct 2005
Posts: 46
|
| Posted: Tue Jul 11, 2006 9:33 am Post subject:
Re: Accessors in Python (getters and setters)
|
|
|
Hello,
Thanks for the responses. The reason I want to change the name of the
attribute is because it doesn't reflect the purpose of the attribute,
anymore. The attribute was originally a string object, but not anymore.
It is primarily a readability issue. There are also a few key
attributes I don't want developers, including myself, fiddling with.
Properties /accessors are good because they allow you to encapsulate
attributes so you can change implementations at will. Some of you have
argued I would have needed to change accessor names too if I had
misnamed them earlier. It's hard to say. I find myself changing the
names of attributes a lot more frequently than I do functions or
methods. Choosing a crappy attribute name is effortless for me,
especially during intense coding sessions. I usually realize I've
choosing a crappy attribute name the next day, sometimes even later.
However, I put a lot more effort into choosing method and function
names, especially when I know it may likely be a public API. Plus it's
really hard to choose crappy accessor name.
Regards |
|
| Back to top |
|
|
bruno modulix
*nix forums Guru
Joined: 21 Feb 2005
Posts: 819
|
| Posted: Tue Jul 11, 2006 11:29 am Post subject:
Re: Accessors in Python (getters and setters)
|
|
|
mystilleef wrote:
| Quote: | Hello,
Thanks for the responses. The reason I want to change the name of the
attribute is because it doesn't reflect the purpose of the attribute,
anymore. The attribute was originally a string object, but not anymore.
It is primarily a readability issue. There are also a few key
attributes I don't want developers, including myself, fiddling with.
Properties /accessors are good because they allow you to encapsulate
attributes so you can change implementations at will. Some of you have
argued I would have needed to change accessor names too if I had
misnamed them earlier. It's hard to say. I find myself changing the
names of attributes a lot more frequently than I do functions or
methods. Choosing a crappy attribute name is effortless for me,
especially during intense coding sessions. I usually realize I've
choosing a crappy attribute name the next day, sometimes even later.
However, I put a lot more effort into choosing method and function
names, especially when I know it may likely be a public API.
|
What you need to understand here is that in Python,
1/ methods *are* attributes
2/ every attribute whose name is not prefixed by a leading underscore is
considered part of the api ('__magic__' names being a special case).
So it has nothing to do with "data vs method" dichotomy (which makes no
sens in a languages where functions and methods are objects), only with
"API vs implementation". You choosed a crappy name for an attribute
that's part of the API, so it's *exactly* the same case as if you had
chosen a crappy name for a public method in Java. Think of public "data"
attributes as magical getter/setters with the most straightforward
behaviour, and of properties as the way to override this default behaviour.
| Quote: | Plus it's
really hard to choose crappy accessor name.
|
What about getMyCrappyAttributeName/setMyCrappyAttributeName ?-)
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])" |
|
| Back to top |
|
|
mystilleef@gmail.com
*nix forums beginner
Joined: 11 Oct 2005
Posts: 46
|
| Posted: Wed Jul 12, 2006 9:17 am Post subject:
Re: Accessors in Python (getters and setters)
|
|
|
Lousy Attribute Name:
self.tmp
Accessors:
set_temporary_buffer
get_temporary_buffer
The attribute name I chose, "tmp" sucks. I have used that name in
dozens of places spanning over 27000 LOC. There's a chance that other
develops might misinterpret exactly what "tmp" does. Plus I don't want
emails from other developers querying me about what "tmp" is/does.
"tmp" is obvious to me, but not necessarily to others. Now compare that
to the accessors. Not only do they improve readability at the expense
of more code, they actually allow me to change the lousily named
attribute "tmp" to "temporary_buffer" without grepping, seding,
searching, replacing and praying. Sure, if you are dealing with less
than a 1000LOC you can get away with using "tmp" or renaming it easily.
But if you are dealing with a much larger code base and more
developers, issues like this rapidly become a nuisance.
Yes, it is possible to name crappy accessors too (e.g set_tmp/get_tmp).
But developers tend to pay more attention to given methods/functions
less crappy names, at least when compared to data attributes. This
stems from the fact that in many languages data attributes aren't
usually part of the API, as well as the whole OO(Encapsulation) blah
blah. I know I would not name the accessors set_tmp/get_tmp, because my
philosophy is that methods/functions need to have meaningful names and
state their intended purpose. I don't hold data attributes to such
standards and I imagine many developers don't either and least based on
other people's code I've read. Plus there are many occassions when
attributes are not intended to be APIs, but eventually become one.
After all most data attributes are created with the purpose of serving
methods.
Bruno Desthuilliers wrote:
| Quote: | mystilleef wrote:
Hello,
Thanks for the responses. The reason I want to change the name of the
attribute is because it doesn't reflect the purpose of the attribute,
anymore. The attribute was originally a string object, but not anymore.
It is primarily a readability issue. There are also a few key
attributes I don't want developers, including myself, fiddling with.
Properties /accessors are good because they allow you to encapsulate
attributes so you can change implementations at will. Some of you have
argued I would have needed to change accessor names too if I had
misnamed them earlier. It's hard to say. I find myself changing the
names of attributes a lot more frequently than I do functions or
methods. Choosing a crappy attribute name is effortless for me,
especially during intense coding sessions. I usually realize I've
choosing a crappy attribute name the next day, sometimes even later.
However, I put a lot more effort into choosing method and function
names, especially when I know it may likely be a public API.
What you need to understand here is that in Python,
1/ methods *are* attributes
2/ every attribute whose name is not prefixed by a leading underscore is
considered part of the api ('__magic__' names being a special case).
So it has nothing to do with "data vs method" dichotomy (which makes no
sens in a languages where functions and methods are objects), only with
"API vs implementation". You choosed a crappy name for an attribute
that's part of the API, so it's *exactly* the same case as if you had
chosen a crappy name for a public method in Java. Think of public "data"
attributes as magical getter/setters with the most straightforward
behaviour, and of properties as the way to override this default behaviour.
Plus it's
really hard to choose crappy accessor name.
What about getMyCrappyAttributeName/setMyCrappyAttributeName ?-)
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])" |
|
|
| Back to top |
|
|
Maric Michaud
*nix forums addict
Joined: 13 May 2006
Posts: 77
|
| Posted: Wed Jul 12, 2006 9:47 am Post subject:
Re: Accessors in Python (getters and setters)
|
|
|
Le mercredi 12 juillet 2006 11:17, mystilleef a écrit :
| Quote: | Yes, it is possible to name crappy accessors too (e.g set_tmp/get_tmp).
But developers tend to pay more attention to given methods/functions
less crappy names, at least when compared to data attributes.
Not python developers. |
| Quote: | This
stems from the fact that in many languages data attributes aren't
usually part of the API, as well as the whole OO(Encapsulation) blah
blah. I know I would not name the accessors set_tmp/get_tmp, because my
philosophy is that methods/functions need to have meaningful names and
state their intended purpose.
But that's not python philosophy. |
| Quote: | I don't hold data attributes to such
standards and I imagine many developers don't either and least based on
other people's code I've read. Plus there are many occassions when
attributes are not intended to be APIs, but eventually become one.
But they are in Python and that is the python's philosophy. All attribute or |
method not beginning with an '_' *is* API.
| Quote: | After all most data attributes are created with the purpose of serving
methods.
And in python the reverse can be true : |
class a(object) :
def __init__(self, ro_attr) : self.__attr = ro_attr
def _getAttr(self) :
"""A method which serves an attribute"""
return self.__attr
attr = property(_getAttr)
--
_____________
Maric Michaud
_____________
Aristote - www.aristote.info
3 place des tapis
69004 Lyon
Tel: +33 426 880 097 |
|
| Back to top |
|
|
bruno modulix
*nix forums Guru
Joined: 21 Feb 2005
Posts: 819
|
| Posted: Wed Jul 12, 2006 11:15 am Post subject:
Re: Accessors in Python (getters and setters)
|
|
|
mystilleef wrote:
| Quote: | Lousy Attribute Name:
self.tmp
Accessors:
set_temporary_buffer
get_temporary_buffer
The attribute name I chose, "tmp" sucks.
|
Well, it's surely not as descriptive as 'temporary_buffer'
| Quote: | I have used that name in
dozens of places spanning over 27000 LOC.
|
Too bad for you.
| Quote: | There's a chance that other
develops might misinterpret exactly what "tmp" does. Plus I don't want
emails from other developers querying me about what "tmp" is/does.
"tmp" is obvious to me, but not necessarily to others.
|
So why did you name it that way at first ?
| Quote: | Now compare that
to the accessors.
|
But 'tmp' actually *is* an accessor.
| Quote: | Not only do they improve readability
|
Err... do you find:
obj.set_temporary_buffer(val)
val = obj.get_temporary_buffer()
really more readable than:
obj.temporary_buffer = val
val = obj.temporary_buffer
| Quote: | at the expense
of more code,
|
Indeed. In both the class and client code.
| Quote: | they actually allow me to change the lousily named
attribute "tmp" to "temporary_buffer" without grepping, seding,
searching, replacing and praying.
|
You still fail to get the point. You actually choose a crappy name for a
*public* property. It's *exactly* as if, in Java, you had named your
getter/setter 'get_tmp' and 'set_tmp'.
| Quote: | Sure, if you are dealing with less
than a 1000LOC you can get away with using "tmp" or renaming it easily.
But if you are dealing with a much larger code base and more
developers, issues like this rapidly become a nuisance.
|
Indeed. But it's *your* responsability to choose good names for the API.
| Quote: | Yes, it is possible to name crappy accessors too (e.g set_tmp/get_tmp).
or 'tmp'. |
| Quote: | But developers tend to pay more attention to given methods/functions
less crappy names, at least when compared to data attributes.
|
s/developpers/you/
| Quote: | This
stems from the fact that in many languages data attributes aren't
usually part of the API,
|
Once again, in Python, there is *no* such thing as 'data attributes'.
*All* attributes are *objects* - some of them callable.
| Quote: | as well as the whole OO(Encapsulation) blah
blah.
|
Don't confuse encapsulation with data-hiding.
| Quote: | I know I would not name the accessors set_tmp/get_tmp, because my
philosophy is that methods/functions need to have meaningful names and
state their intended purpose.
|
That's true for each and every name in a program.
| Quote: | I don't hold data attributes to such
standards
|
Too bad for you.
| Quote: | and I imagine many developers don't either and least based on
other people's code I've read. Plus there are many occassions when
attributes are not intended to be APIs,
|
Then mark them as being implementation (ie : prefix them with a single
underscore).
| Quote: | but eventually become one.
After all most data attributes are created with the purpose of serving
methods.
|
Nope. You have the class API, and the class implementation. Both made of
both callable and non-callable attributes.
Mystilleef, I do share your pain (really - been here, done that,
etc...), and I understand that grasping Python requires some mental
adjustments when coming from Java and friends (been here, done that,
etc...). But you seriously can't blame the language for your own mistakes.
If you intented 'tmp' to be part of the API, then you're responsible for
the bad naming. If you didn't, then you're responsible for breaking the
encapsulation - FWIW, following the convention (single leading
underscore) could have make it clearer to you. In both cases, you
happily used a bad name in 27 KLOC - so you really had a lot of time and
occasions to notice something wrong with this.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])" |
|
| Back to top |
|
|
Gerhard Fiedler
*nix forums beginner
Joined: 12 Jul 2006
Posts: 18
|
| Posted: Wed Jul 12, 2006 11:58 am Post subject:
Re: Accessors in Python (getters and setters)
|
|
|
On 2006-07-12 06:17:27, mystilleef wrote:
| Quote: | But developers tend to pay more attention to given methods/functions
less crappy names, at least when compared to data attributes. This
stems from the fact that in many languages data attributes aren't
usually part of the API, as well as the whole OO(Encapsulation) blah
blah.
|
I'm not sure about which languages you are talking (pretty much all that
allow public methods also allow public attributes), but in general I think
you should get away from the distinction attribute vs method (which doesn't
make much sense in any language) and start looking at the distinction
public vs private (which is what you really are talking about) -- and start
giving the appropriate care to naming public entities, no matter /what/
they are. (Besides, I don't know many coding rules that say that creating
an accessor get/setTemporaryBuffer that acts on the private member tmp is
good style.)
I'm just starting to get started with Python, but it seems that the leading
underscore marks private entities. So why don't you precede everything with
an underscore that doesn't have a name that fulfills your criteria for a
decent public name -- no matter what kind of entity it is?
It seems you are basically complaining that you used a crappy name in a
public API. Well... you shouldn't, not in Python, and not in any other
language And there's no way around it, not in Python, and not in any
other language, than to rename that entity in the public API. Which can be
a major hassle, close to impossible. There are all kinds of public APIs
with crappy names (using accessors and all that got created early on and
never changed. Stuff happens.
Maybe you didn't know about the underscore way to mark private entities.
Maybe this doesn't work as I think it does (from reading this thread). But
maybe it does, and maybe that's then just part of the learning curve for
you. (And I'm sure you're not alone... :)
Gerhard |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Sat Nov 22, 2008 8:07 am | All times are GMT
|
|
Mortgages | Buy Shares | MPAA | Unique MySpace Layouts | Credit Cards
|
|
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
