[PYTHON MATRIX-SIG] Attributes vs. methods

[Jim Fulton, U.S. Geological Survey]

On Jan 19, 11:29am, Paul. Dubois wrote:
> Subject: [PYTHON MATRIX-SIG] Attributes vs. methods
> Pardon in advance if this gets too pedantic; I figured the range of OOP
> experience varies so I go somewhat slow. The question before the SIG is
> whether, for example, it should be x.shape or x.shape().
>
> First, speaking in abstract OOP terms, a class can have two kinds of
> members, attributes and methods. The former is data, the latter is
> executable. In some languages (but not all) you can tell which kind of
> access is being made just by looking at it:
> x.f   -- f is data
> x.f() -- f is a method
>
> (Aside: this is not a GoodThing. It forces the implementor of a class to
> commit to a representation for f, ie. to decide once and for all how
> clients will refer to f. For example, if f represents a certain
> quantity, say pressure, a decision is made immediately as to whether f
> is to be a primary state variable or whether to calculate it from
> something else, like the temperature. It is better if a data attribute
> is indistinguishable from the client's point of view from a function
> that takes no arguments. Eiffel has this right.)
>
> That said, one then has to ask whether a certain language allows
> statements of the form
>
> x.f = something
>
> If it does, then maintaining the object as an abstract data type become
> difficult. For example, we may have two attributes x and y and we want
> to ensure a certain relationship always holds between them. Obviously,
> if any old user can come along and assign something to x without
> changing y, we have problems. Thus, in many languages that allow
> assignment to x.f, books are written advising that all such f's be
> hidden (private) and that a function x.f() be supplied to the users
> instead. Then one worries about inlining, etc.
>
> In Python, the situation is more complicated. There is no "private".

All data in built-in types is private.  Data in class instances can be made
semi-private, with some effort.  Actually, I hope that in the future there will
be alternate class types that support features such as private attributes.

> So,
> a convention has developed that if an attribute has a name beginning
> with an underscore, then the warranty on the object is void if the
> client assigns to it. This is a reasonable compromise in that the usual
> strategy of having an f() and a set_f(value) may suffer some performance
> penalty since inlining isn't going to be done, and anyway there is no
> private data anyway.
>
> Next, Python allows one to make it appear that f is an attribute even if
> it is not, so that while x.f "works" there really isn't such a data
> member and x.f = something would not be setting it (and may even fail,
> depending on the way the class was written). However, learning about
> this trick implies a level of sophistication beyond the level to be
> expected in the user of an application in which Python is used as the
> scripting language. Such a user is too likely to try to change the shape
> of the matrix by assignment.

This argument assumes that the unsophisticated user is sophisticated enough to
worry about the implementation in the first place.

> So, my conclusion is that if x.shape in the matrix class is an
> attribute, and we don't want any user to do x.shape=something, we should

I'd be inclined to think about this a little differently.  I think it is
reasonable for an interface to expose properties, where properties represent
information that you can query and set for the object, without regard to
implementation.

I'd be inclined to agree that if you don't want to allow:

  x.shape = something

then shape should probably not be modeled as an attribute, however,
these same argument might be used to say that if you can say:

  "spam"[0]

you should also able to say:

  "spam"[0]="S"

> call it _shape, and supply an x.shape() for normal access. I think this
> argument applies to the level intended for use by the general public.
> They need a simple, consistent set of rules to live by.

I'm not really disagreeing with you, but I find the idea of abstract attributes
to be interesting.

Jim



=================
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================