Summer reading list

[Chad Netzer]

On Tue, 2003-08-12 at 11:32, Joe Cheng wrote:

> > True.  But the flexibility of using the builtin is also nice.  For
> > example, you can add a bunch of objects to the list, then 
> > heapify once,

> Hmmm, I'm not sure if I buy this particular argument.  Line 5 in my
> examples there was supposed to illustrate constructing a heap from a
> list--so you could do pretty much the same thing.

True.  I am am very sympathetic with your point of view, because I am
developing a signal transform package which has many of the same
issues.  I take a signal (say a list of numbers), do a transform, then
return the coefficients.  Rather than having a function which does the
transform, returning just list of coefficients, I make a class which
provide transformer objects.  These objects do the work, and return the
coefficients bundled in another yet object which contains the
transformed coefficients, plus other data that is needed to do an
inverse transform.

So, in essence, I think in terms of services.  An object provides the
"service" of transforming some raw data.  The resulting object also
provides the "service" of (properly) inverting the data, as well as
doing some simple manipulations of it.

The reason for doing things this way, is because, as you say, exposing
just a list would allow for the opportunity for the results to be
improperly mutated or mishandled (ie. pop()-ing from the resulting list
would be disastrous).  However, when I show this approach to colleages,
many grit and gnash their teeth.  They would like to simply have the
transformed coefficients to operate on directly (this is what they are
used to doing in functional paradigms).  They know the result of a
transform is a list of coefficients (that is what the textbooks say),
and they do not want perform extra steps to "pull out" just the
coefficients.

In general, this is a widespread concern in fields where raw data is
manipulated with algorithms.  Should one encapsulate resultant data (ie.
bundle the ralted peices all up in a special class), or just return data
as simple, common objects (ie. lists and arrays) that can be operated on
universally.

I'd say that this case (heapq) is similar, and the author simply made
the choice that was comfortable with him.  Still, since the heap is
defined more by operations than state (ie. other than a list, there
isn't much extra state that needs to be encapsulated in a heap object),
I think I also prefer the approach of having a class that defines just
what operations can be performed.  Construction can easily be used to
make new heaps, and (in principle), a list comprehension can easily
extract the list from the heap object.  In this way, when you pass me a
heap, I know it is a heap by its type.


> I hope you are not suggesting there is also something to be gained by
> directly manipulating the list as a list after it has been heapified? :)

I won't, but perhaps others will. :)  I honestly don't know what is to
be gained from operating on the list directly, once it has been
heapified.  Probably it conforms to an existing, popular, interface for
dealing with heaps (ie. C arrays, with functions that manipulate them). 
Or perhaps it is so foten operated on as a list, that it was easiest to
always keep it a list.


> I've never heard this idea before... I'll need to chew on it a little.
> Is this a common notion among Pythoners?
> 
> To me it sounds disturbingly like "Procedures are more flexible than
> classes because you can compose classes out of procedures."

I don't think most Pythoners would accept that quote.  I just think, in
this case, some might say "Try to use the builtin types to do your
work.  If you create functions that manipulate them, you can also reuse
those functions in your classes." :)

Or even more likely, "In Python, it is easy to stick a Class interface
onto a functional API.  If that makes you comfortable, do it." :)

I offer those partly in jest, and partly as serious advice.

Perhaps Kevin O'Connor or Tim Peters will comment more on the heapq
interface.  One could always propose an (additional) class based
interface to be included as a standard part of the module, with likely
some >0 percent chance of it being accepted.

In any case, I think it raises some good issues worth thinking about and
discussing.

-- 
Chad Netzer