Accessors in Python (getters and setters)

[mystilleef]

Bruno Desthuilliers wrote:
> 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.

>
> > 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.

> > Now compare that
> > to the accessors.
>
> But 'tmp' actually *is* an accessor.

I didn't say it wasn't.
>
> > 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.

>
> > 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.

> > 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.

> > 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.

> > 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.

> > as well as the whole OO(Encapsulation) blah
> > blah.
>
> Don't confuse encapsulation with data-hiding.

I don't see the confusion.

>
> > 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.

> > 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.

> > 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.

> 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.

> 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.

>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