«

> > It might just be my Java background creeping in (I'm a
> Python newbie), but,
> > wouldn't it be better if this was OO?
> >
> > heap = Heap()
> > heap.push(item)
> > item = heap.pop()
> > item = heap[0]
> > heapified = Heap(x)
> > item = heap.replace(item)
> >
> > Otherwise the user could easily break the heap by doing
> something dumb to
> > the list...
>
> 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,
> rather than having to call heap.push() a bunch of times (which may be
> slower, because you need to maintain the heap property after you push
> each new item.)

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.

list = [1, 19, 33, 40]
heap = Heap(list)

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?

Oh, and of course a heap class should probably support a to_list()
export function (that returns a _copy_ of the internal list).

> I think the idea is that, if you want a real Heap class, you can build
> one very easily (see below). And if you don't need a heap class, you
> can gain some benefits from this approach because it is exposing and
> operating on lists directly.

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'd worry
that the proliferation of procedures would undermine good OO, which
wants coupling at the class interface level. Meanwhile you gain nothing
by using the raw procedures instead of dealing with the class. (Haven't
thought too much about this, so I could be way off...?)

> This probably comes under "practicality beats purity". (See
> 'The Zen of
> Python', or type "import this" into your Python interpreter)

I don't consider myself an OO purist. However, in practical terms, I'd
much rather work with a "black box" heap than one where I carry around
its state in a mutable data structure...

"Joe Cheng" <> wrote in message news:<mailman.1060713261.4958.python->...
> To me it sounds disturbingly like "Procedures are more flexible than
> classes because you can compose classes out of procedures."

I would subscribe that. Not that I dislike inheritance, but I don't kill
a mosquito with a bazooka.

Let me give a real life example, happened to me recently.

I had a class manipulating text, with a "dedent" method. It turns out
that the "textwrap" module included in the Python 2.3 distribution
contains a "dedent" function doing exactly the same.
Then I had the satisfaction of killing my own implementation,
and to add to my class the textwrap.dedent function just with one
line of code, "dedent=staticmethod(textwrapper.dedent)". I am
very happy with that because:

1) I shortened my class;
2) I reused pre-existing code;
3) I trust the developers of the standard library more than myself;
4) If the standard library contains bugs, they are much more easily
discovered than my own bugs;
5) the burden to fix them is up the Python developers, not me

The fact that "dedent" was a function and not a method in a class
made my life easier. I had not to worry about inheriting from another
class with potential name clashes with my own, and "dedent" was the
only function I needed.

Fortunately, quite a lot of modules in the standard library are
written without a class interface and I would date say I have never
seen an example of usage of a class when the class is not needed.

In other words: most of the time a lightweight approach is more than
appropriate, why should I be forced to take a heavy weight approach?
The fact of having "free" functions (i.e. not bounded to classes) is
to me a big strenght of Python and it helps reuse of code quite a lot.

To reuse classes is good, but typically only works when you know
about the class you want to inherit *before* you start coding your
own class; on the other hand, it is quite easy to add functions
or methods to your class even *after* you wrote it.

Moreover, this is nothing wrong about using many short modules collecting
utilities functions, you will never clutter your namespace, if you use
a minimum of care (even globals are globals only in their module,
I love that!

I tend to code in terms of small functions, then I compose them in
small classes, then I compose the classes in modules. When I am
done, I play with metaclasses if I need to modify what I wrote
with a minimum of effort.

There are quite few languages that can give you such a flexibility,
and no one simpler to use than Python.

Just my own view,


Michele

(Michele Simionato) writes:

> "Joe Cheng" <> wrote in message
> news:<mailman.1060713261.4958.python->...
> > To me it sounds disturbingly like "Procedures are more flexible than
> > classes because you can compose classes out of procedures."
>
> I would subscribe that. Not that I dislike inheritance, but I don't kill
> a mosquito with a bazooka.
>
> Let me give a real life example, happened to me recently.
>
> I had a class manipulating text, with a "dedent" method. It turns out
> that the "textwrap" module included in the Python 2.3 distribution
> contains a "dedent" function doing exactly the same.
> Then I had the satisfaction of killing my own implementation,
> and to add to my class the textwrap.dedent function just with one
> line of code, "dedent=staticmethod(textwrapper.dedent)". I am
> very happy with that because:

[...snip usual reasons for reusing code...]

> The fact that "dedent" was a function and not a method in a class
> made my life easier. I had not to worry about inheriting from another
> class with potential name clashes with my own, and "dedent" was the
> only function I needed.
>
> Fortunately, quite a lot of modules in the standard library are
> written without a class interface and I would date say I have never
> seen an example of usage of a class when the class is not needed.
>
> In other words: most of the time a lightweight approach is more than
> appropriate, why should I be forced to take a heavy weight approach?
> The fact of having "free" functions (i.e. not bounded to classes) is
> to me a big strenght of Python and it helps reuse of code quite a lot.

All fine.


> To reuse classes is good, but typically only works when you know
> about the class you want to inherit *before* you start coding your
> own class; on the other hand, it is quite easy to add functions
> or methods to your class even *after* you wrote it.
[...]

But I don't think that makes any sense. As I'm certain you know,
there would be nothing to stop you using a class in exactly the same
way you used the function, because reuse != inheritance. Functions
can be implemented in terms of classes, and classes can be implemented
in terms of functions.

The only reason it's good that Python library uses functions sometimes
instead of classes is as you say: KISS. If it only needs a function,
use a function.


John

(John J. Lee) wrote in message news:<>...
> (Michele Simionato) writes:
> > To reuse classes is good, but typically only works when you know
> > about the class you want to inherit *before* you start coding your
> > own class; on the other hand, it is quite easy to add functions
> > or methods to your class even *after* you wrote it.
> [...]
>
> But I don't think that makes any sense. As I'm certain you know,
> there would be nothing to stop you using a class in exactly the same
> way you used the function, because reuse != inheritance. Functions
> can be implemented in terms of classes, and classes can be implemented
> in terms of functions.

Let me see if I understand what you mean. You are saying "I could invoke
an instance method just as I invoke a function, without using inheritance,
and reuse the method in another class". True, but this is clumsy: the point
of using a class is making use of inheritance for code reuse, otherwise I
could just use a function, isn't it? Besides, typically an instance
method is doing something to the 'self' argument and may have unwanted
side effects on the object; a function is safer in this respect.
In my experience, it takes a certain effort to code a reusable class;
it takes a much lesser effort to code a reusable function.

> The only reason it's good that Python library uses functions sometimes
> instead of classes is as you say: KISS. If it only needs a function,
> use a function.
>
> John

Yep.

Michele