classes (was Re: Same again please for OOP)

[Alex Martelli]

"Erno Kuusela" <erno-news at erno.iki.fi> wrote in message
news:kuy9x4seef.fsf at lasipalatsi.fi...
    [snip]
> | Giving accessor methods uniform names is hardly a minus, and
> | starting them with something suggesting 'get' is particularly good.
>
> even easier than __get_location(self) is get_location(self) ;)

No!  You have to type __get_location(self) *ONCE*, when
implementing your class; client-code has to type foo.get_location()
a ZILLION times, whenever it needs to access that attribute.

Saving two leading underlines ONCE, and paying with 6 extra
characters PLUS the possible error of omitting the '()':-), a
zillion times -- 'penny-wise, pound-foolish' comes to mind.

Just let clients use foo.location and be happy...


> | example is: obj.price *= 1.07 # 7% increase versus
> | obj.setPrice(obj.getPrice() * 1.07) # 7% increase
>
> | Why force client code to go through the latter, more complicated
> | form, when the simpler first form is available so cheap?
>
> because, the latter is simpler. yes, it is more tedious to type. i
> count this against augmented assignment :)

"I want to multiply the object price by 1.07" is simpler when
expressed just as such.


> | Why force client-code to know and remember which attributes
> | are actually 'in' the original object (and thus must be accessed
> | through accessor methods, in your style) and which ones aren't (and
> | thus must be accessed directly, unless one goes to the serious
> | trouble of building up an accessor method and sticking it on
> | on-the-fly -- blah!)...?
>
> interesting point. i've never done this, seems like dubious practice
> at first sight.

It's very handy & Pythonic.  And Javascript'ers do it all the time,
so as they discover Python you'll see it happen more and more.


> | These are pragmatical considerations that make direct, simpler
> | notation preferable.  On a _conceptual_ plane, the key issue is not
> | confusing state and behavior.  "Methods BEHAVE -- they DO stuff" and
> | "properties JUST ARE -- I can 'read' them, and some of them I may
> | also be allowed to 'write'" is a good pair of rules-of-thumbs to use
> | as guidelines in deciding how to model something -- method, or
> | property (attribute)?  It's a very similar distinction to that
> | between functions and variables.
>
> so, you'd prefer most of the string methods that take no args in
> python 2.0 were actually attributes? i don't know, somehow
> doesn't seem pythonic to me.

Nah -- I don't think of a string as 'carrying around' versions of
itself in all kinds of funky cases, or severally stripped, &c -- I
think of each of this as computational behavior, not *state*, of
the string-object.


Alex