473,837 Members | 1,758 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Accessors in Python (getters and setters)

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.

Regards

Jul 10 '06
112 13891
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

Jul 11 '06 #11
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 getMyCrappyAttr ibuteName/setMyCrappyAttr ibuteName ?-)

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom. gro'.split('@')])"
Jul 11 '06 #12
Lousy Attribute Name:
self.tmp

Accessors:
set_temporary_b uffer
get_temporary_b uffer

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_buff er" 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(Encapsulatio n) 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:
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 getMyCrappyAttr ibuteName/setMyCrappyAttr ibuteName ?-)

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom. gro'.split('@')])"
Jul 12 '06 #13
Le mercredi 12 juillet 2006 11:17, mystilleef a écrit*:
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.
This
stems from the fact that in many languages data attributes aren't
usually part of the API, as well as the whole OO(Encapsulatio n) 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.
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.
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(_getAt tr)


--
_____________

Maric Michaud
_____________

Aristote - www.aristote.info
3 place des tapis
69004 Lyon
Tel: +33 426 880 097
Jul 12 '06 #14
mystilleef wrote:
Lousy Attribute Name:
self.tmp

Accessors:
set_temporary_b uffer
get_temporary_b uffer

The attribute name I chose, "tmp" sucks.
Well, it's surely not as descriptive as 'temporary_buff er'
I have used that name in
dozens of places spanning over 27000 LOC.
Too bad for you.
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 ?
Now compare that
to the accessors.
But 'tmp' actually *is* an accessor.
Not only do they improve readability
Err... do you find:

obj.set_tempora ry_buffer(val)
val = obj.get_tempora ry_buffer()

really more readable than:

obj.temporary_b uffer = val
val = obj.temporary_b uffer

at the expense
of more code,
Indeed. In both the class and client code.
they actually allow me to change the lousily named
attribute "tmp" to "temporary_buff er" 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'.
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.
Yes, it is possible to name crappy accessors too (e.g set_tmp/get_tmp).
or 'tmp'.
But developers tend to pay more attention to given methods/functions
less crappy names, at least when compared to data attributes.
s/developpers/you/
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.
as well as the whole OO(Encapsulatio n) blah
blah.
Don't confuse encapsulation with data-hiding.
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.
I don't hold data attributes to such
standards
Too bad for you.
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).
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 'o****@xiludom. gro'.split('@')])"
Jul 12 '06 #15
Ant
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
In my experience of getters and setters in Java, most developers choose
attribute names first, and then use the IDE (Java without an IDE
*really* sucks) to auto-generate the getters and setters. So most Java
developers I have worked with pay more attention to attributes than
accessor names as these are derived anyway. So I guess it depends on
who the developers are ;-)

Jul 12 '06 #16
On 2006-07-12 06:17:27, mystilleef wrote:
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(Encapsulatio n) 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/setTemporaryBuf fer 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

Jul 13 '06 #17
Gerhard Fiedler <ge*****@gmail. comwrote:
...
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
Smalltalk is a very well known object-oriented language that behaves
otherwise, just as one example.
Alex
Jul 13 '06 #18
Maric Michaud wrote:
Not python developers.
Nonsense!
But that's not python philosophy.
Python doesn't have any philosophy with regards to naming identifiers.
But they are in Python and that is the python's philosophy. All attribute or
method not beginning with an '_' *is* API.
Right, and what if I want to change a private API to a public one. How
does that solve my naming issues.
And in python the reverse can be true :
The reverse is hardly ever true. 90% of public APIs in almost all
languages are methods or functions.

Jul 13 '06 #19
In <11************ **********@35g2 000cwc.googlegr oups.com>, mystilleef
wrote:
Maric Michaud wrote:
>But that's not python philosophy.
Python doesn't have any philosophy with regards to naming identifiers.
But the python community has one. Pythonistas prefer readable source code
so they tend to think about good names. As The Zen of Python says
“Readability counts.”
>But they are in Python and that is the python's philosophy. All attribute or
method not beginning with an '_' *is* API.
Right, and what if I want to change a private API to a public one. How
does that solve my naming issues.
Then you have to change all references to that private attribute. What's
the problem here? As it was private I would expect to find all the
references "nearby" in the same module or class.
>And in python the reverse can be true :
The reverse is hardly ever true. 90% of public APIs in almost all
languages are methods or functions.
Except the ones with properties where ordinary "attributes " may be just
calls in disguise.

Python is not almost all other languages and in Python code you usually
won't find those trivial getters and setters because we have properties if
the access might become a bit more complex in the future.

Ciao,
Marc 'BlackJack' Rintsch
Jul 13 '06 #20

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

10
5798
by: Zap | last post by:
Widespread opinion is that public data members are evil, because if you have to change the way the data is stored in your class you have to break the code accessing it, etc. After reading this (also copied below for easier reference): http://groups.google.it/groups?hl=en&lr=&safe=off&selm=6beiuk%24cje%40netlab.cs.rpi.edu&rnum=95 I don't agree anymore.
21
1927
by: Raj | last post by:
Hi, We just executed a project with Python using TG. The feedback was to use more python like programming rather than C style code executed in Python. The feedback is from a Python purist and for some reasons we cannot solicity his help. So we'd like to do is to scrub through the codebase and identify places where the codebase needs improvement, both from styling as well as design. Is there any website that can provide me with...
0
9846
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
9685
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
10580
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
0
10277
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
9413
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
1
7817
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
5674
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
0
5853
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
2
4052
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.