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.
> 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_temporary_buffer(val)
val = obj.get_temporary_buffer()
really more readable than:
obj.temporary_buffer = val
val = obj.temporary_buffer
> 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'.
> 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(Encapsulation) 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 '[EMAIL PROTECTED]'.split('@')])"
--
http://mail.python.org/mailman/listinfo/python-list
