|
|
|
|
|
|
| Author |
Message |
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 |
|
 |
antroy@gmail.com
*nix forums addict
Joined: 24 May 2006
Posts: 52
|
| Posted: Wed Jul 12, 2006 12:29 pm Post subject:
Re: Accessors in Python (getters and setters)
|
|
|
| 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. 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  |
|
| Back to top |
|
|
Dennis Lee Bieber
*nix forums Guru
Joined: 05 Mar 2005
Posts: 819
|
| Posted: Thu Jul 13, 2006 4:27 am Post subject:
Re: Accessors in Python (getters and setters)
|
|
|
On Wed, 12 Jul 2006 08:58:17 -0300, Gerhard Fiedler <gelists@gmail.com>
declaimed the following in comp.lang.python:
| Quote: | 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
|
It is a convention that signals the intent of the attribute is to be
private. Nothing in Python enforces a distinction. Double underscores
invoke name-mangling to allow for access to parent class members that
might otherwise be shadowed.
--
Wulfraed Dennis Lee Bieber KD6MOG
wlfraed@ix.netcom.com wulfraed@bestiaria.com
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: web-asst@bestiaria.com)
HTTP://www.bestiaria.com/ |
|
| Back to top |
|
|
Alex Martelli
*nix forums Guru
Joined: 19 Feb 2005
Posts: 955
|
| Posted: Thu Jul 13, 2006 4:50 am Post subject:
Re: Accessors in Python (getters and setters)
|
|
|
Gerhard Fiedler <gelists@gmail.com> wrote:
...
| Quote: | 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 |
|
| Back to top |
|
|
mystilleef@gmail.com
*nix forums beginner
Joined: 11 Oct 2005
Posts: 46
|
| Posted: Thu Jul 13, 2006 8:14 am Post subject:
Re: Accessors in Python (getters and setters)
|
|
|
Maric Michaud wrote:
| Quote: | Not python developers.
Nonsense!
But that's not python philosophy.
Python doesn't have any philosophy with regards to naming identifiers. |
| Quote: | 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.
| Quote: | 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. |
|
| Back to top |
|
|
Marc 'BlackJack' Rintsch
*nix forums Guru Wannabe
Joined: 03 Mar 2005
Posts: 146
|
| Posted: Thu Jul 13, 2006 8:34 am Post subject:
Re: Accessors in Python (getters and setters)
|
|
|
In <1152778446.236509.151730@35g2000cwc.googlegroups.com>, mystilleef
wrote:
| Quote: | 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.”
| Quote: | 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.
| Quote: | 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 |
|
| Back to top |
|
|
bruno modulix
*nix forums Guru
Joined: 21 Feb 2005
Posts: 819
|
| Posted: Thu Jul 13, 2006 8:49 am Post subject:
Re: Accessors in Python (getters and setters)
|
|
|
mystilleef wrote:
(snip)
| Quote: | Python doesn't have any philosophy with regards to naming identifiers.
|
Yes it does.
| Quote: |
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.
|
Then you provide a public API on top of the private one.
class MyClass(object):
def __init__(self, ...):
self._attr = XXX
# seems like we really have enough use
# cases to justify exposing _imp_attr
@apply
def attr():
def fget(self):
return self._attr
def fset(self):
self._attr = attr
return property(**locals())
def _method(self, ...):
# code here
# seems like we really have enough use
# cases to justify exposing _imp_method
method = _impmethod
Note that none of this actually breaks encapsulation.
| Quote: | How
does that solve my naming issues.
|
How could this solve *your* naming issue ? This is totally unrelated.
You choose a bad name for a *public* symbol.
| Quote: | And in python the reverse can be true :
The reverse is hardly ever true.
|
So what are computed attributes ?
| Quote: | 90% of public APIs in almost all
languages are methods or functions.
|
"allmost all languages" lacks computed attributes.
--
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: Thu Jul 13, 2006 8:50 am Post subject:
Re: Accessors in Python (getters and setters)
|
|
|
Bruno Desthuilliers wrote:
| Quote: | mystilleef wrote:
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'
I have used that name in
dozens of places spanning over 27000 LOC.
Too bad for you.
|
Thank you, that was helpful.
| 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 ?
|
What does it matter? There are 10 million and one reasons from given
identifiers bad names.
| Quote: | Now compare that
to the accessors.
But 'tmp' actually *is* an accessor.
|
I didn't say it wasn't.
| 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
|
I didn't name the attribute temporary_buffer, I named it tmp.
| Quote: |
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_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'.
|
No, it isn't. In Java there's a clear distinction between attributes
and methods.
| 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.
|
I choose good names for most of my APIs. But there cases when you never
know an attribute will actually be an API before hand.
| Quote: | 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/
|
Ha, right! I bet you are perfect developer.
| 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.
|
I didn't say attributes weren't objects.
| Quote: | as well as the whole OO(Encapsulation) blah
blah.
Don't confuse encapsulation with data-hiding.
|
I don't see the confusion.
| 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.
I don't hold data attributes to such
standards
Too bad for you.
|
Thank 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).
|
I thought that too was unpythonic.
| 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.
Or objects have state and behavior. Data attributes represent state and |
methods represent behavior.
| Quote: | 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.
|
You don't share my pain. You seem to mock it. I'm not new to Python
either. I've been using it for over 2 years in several capacities. I
only recently decided to use it for a large project.
| Quote: | If you intented 'tmp' to be part of the API, then you're responsible for
the bad naming.
|
I never intended it to be part of the API. It evolved to be an
important part of the system.
| Quote: | 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.
That's nonsense. I only just noticed because I was trying to implement |
a plug-in system and I needed to expose an important class. I would not
have considered the issue a problem without this requirement. Except
you are a prophet, you sometimes can't know before hand how certain
classes will end up being used especially if requirements suddenly
change. Saying it's my fault to make yourself feel better about your
favorite language doesn't help solve my problem. I didn't come here to
be berated. I came here to learn the Pythonic way to implementing
accessors. And of course how to deal with issues like the one I have in
medium size to large scale projects. People make mistakes, we deal with
an move on. Sheesh |
|
| Back to top |
|
|
mystilleef@gmail.com
*nix forums beginner
Joined: 11 Oct 2005
Posts: 46
|
| Posted: Thu Jul 13, 2006 8:59 am Post subject:
Re: Accessors in Python (getters and setters)
|
|
|
Marc 'BlackJack' Rintsch wrote:
| Quote: | In <1152778446.236509.151730@35g2000cwc.googlegroups.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."
I'm glad I'm in tune with the "python community."
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.
Right, but tmp isn't private.
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.
|
Crap! Even in Python too most Public APIs are methods and functions.
| Quote: | 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.
|
Ha! I bet you haven't read too many Python codes.
| Quote: | Ciao,
Marc 'BlackJack' Rintsch |
|
|
| Back to top |
|
|
bruno modulix
*nix forums Guru
Joined: 21 Feb 2005
Posts: 819
|
| Posted: Thu Jul 13, 2006 9:03 am Post subject:
Re: Accessors in Python (getters and setters)
|
|
|
Gerhard Fiedler wrote:
| Quote: | 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(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 even less when one have first-class functions and computed
attributes... In Python, a method is nothing more than a callable attribute.
| Quote: | and start looking at the distinction
public vs private
|
Since "public" and "private" are now strongly connoted with
"language-inforced access restriction", I'd rather talk of "interface vs
implementation"
| Quote: | (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.
|
Yes, it means "implementation, don't touch or you're on your own".
| Quote: | 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.
|
Obviously... And blaming the language for this won't help.
| Quote: | 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
|
If you think that single leading underscores have a special meaning for
the compiler/interpreter, then you got it wrong. It's a convention. Like
using ALL_CAPS for pseudo-constants. Nothing prevents you from accessing
implementation or modifying "constants" - but then you're on your own
and must not complain when something breaks.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])" |
|
| Back to top |
|
|
Fredrik Lundh
*nix forums Guru
Joined: 20 Feb 2005
Posts: 2415
|
| Posted: Thu Jul 13, 2006 9:04 am Post subject:
Re: Accessors in Python (getters and setters)
|
|
|
"mystilleef" wrote:
| Quote: | Right, and what if I want to change a private API to a public one. How
does that solve my naming issues.
|
if your code is as muddled as your rhetorics, your only solution might be
to give up programming.
</F> |
|
| Back to top |
|
|
mystilleef@gmail.com
*nix forums beginner
Joined: 11 Oct 2005
Posts: 46
|
| Posted: Thu Jul 13, 2006 9:05 am Post subject:
Re: Accessors in Python (getters and setters)
|
|
|
Bruno Desthuilliers wrote:
| Quote: | mystilleef wrote:
(snip)
Python doesn't have any philosophy with regards to naming identifiers.
Yes it does.
|
No it doesn't.
| Quote: |
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.
Then you provide a public API on top of the private one.
class MyClass(object):
def __init__(self, ...):
self._attr = XXX
# seems like we really have enough use
# cases to justify exposing _imp_attr
@apply
def attr():
def fget(self):
return self._attr
def fset(self):
self._attr = attr
return property(**locals())
def _method(self, ...):
# code here
# seems like we really have enough use
# cases to justify exposing _imp_method
method = _impmethod
Note that none of this actually breaks encapsulation.
|
Ha! Just as bad as getters and setter.
| Quote: | How
does that solve my naming issues.
How could this solve *your* naming issue ? This is totally unrelated.
You choose a bad name for a *public* symbol.
|
My point exactly! It doesn't solve my problem!
| Quote: | And in python the reverse can be true :
The reverse is hardly ever true.
So what are computed attributes ?
90% of public APIs in almost all
languages are methods or functions.
"allmost all languages" lacks computed attributes.
*sighs* |
|
|
| Back to top |
|
|
bruno modulix
*nix forums Guru
Joined: 21 Feb 2005
Posts: 819
|
| Posted: Thu Jul 13, 2006 9:06 am Post subject:
Re: Accessors in Python (getters and setters)
|
|
|
Marc 'BlackJack' Rintsch wrote:
| Quote: | In <1152778446.236509.151730@35g2000cwc.googlegroups.com>, mystilleef
wrote:
Maric Michaud wrote:
(snip)
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.
|
Not even - cf my answer on this point.
--
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: Thu Jul 13, 2006 9:16 am Post subject:
Re: Accessors in Python (getters and setters)
|
|
|
Fredrik Lundh wrote:
| Quote: | "mystilleef" wrote:
Right, and what if I want to change a private API to a public one. How
does that solve my naming issues.
if your code is as muddled as your rhetorics, your only solution might be
to give up programming.
/F
There's no correlation between rhetorics and programming. That's like |
me saying if you are trying to be sarcastic your only solution might be
to give up programming. |
|
| Back to top |
|
|
bruno modulix
*nix forums Guru
Joined: 21 Feb 2005
Posts: 819
|
| Posted: Thu Jul 13, 2006 9:20 am Post subject:
Re: Accessors in Python (getters and setters)
|
|
|
mystilleef wrote:
| Quote: | Marc 'BlackJack' Rintsch wrote:
In <1152778446.236509.151730@35g2000cwc.googlegroups.com>, mystilleef
wrote:
Maric Michaud wrote:
(snip) |
| Quote: | 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.
Right, but tmp isn't private.
|
Right, but that's your choice. Would you complain about "almost any
other language" if you had to hunt a badly named public method thru 27KLOC ?
(snip)
| Quote: | 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.
Ha! I bet you haven't read too many Python codes.
I have read tens of thousands LOC of Python in the seven past years. |
Computed attributes came in with 2.2x IIRC, so there's a lot of 'legacy'
code that uses getters and setters. Porting this code to a
computed-attribute style would break all client code. Having the two
schemes coexisting would make for bloated APIs and
too-many-ways-to-do-it. So we live with this until Py3K. And none of
these considerations contradicts the point that there's no more use for
javaish getters/setters in Python, nor that javaish getters/setters are
not pythonic.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])" |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Sat Nov 22, 2008 5:18 am | All times are GMT
|
|
Books | Free Credit Reports | Mobile Phone | Western Union Money Transfer | Internet Advertising
|
|
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
