RE: Summer reading list

Discussion in 'Python' started by Joe Cheng, Aug 12, 2003.

  1. Joe Cheng

    Joe Cheng Guest

    > > 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, Aug 12, 2003
    #1
    1. Advertising

  2. "Joe Cheng" <> wrote in message news:<>...
    > 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, Aug 13, 2003
    #2
    1. Advertising

  3. Joe Cheng

    John J. Lee Guest

    (Michele Simionato) writes:

    > "Joe Cheng" <> wrote in message
    > news:<>...
    > > 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, Aug 15, 2003
    #3
  4. (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
    Michele Simionato, Aug 16, 2003
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Volkan Arslan
    Replies:
    0
    Views:
    328
    Volkan Arslan
    Mar 2, 2004
  2. Raymond Hettinger

    Summer reading list

    Raymond Hettinger, Aug 12, 2003, in forum: Python
    Replies:
    6
    Views:
    297
    Fredrik Lundh
    Aug 13, 2003
  3. David Ascher
    Replies:
    0
    Views:
    236
    David Ascher
    Jun 2, 2005
  4. Neal Norwitz

    Summer of Code mailing list

    Neal Norwitz, Apr 28, 2006, in forum: Python
    Replies:
    0
    Views:
    275
    Neal Norwitz
    Apr 28, 2006
  5. Michael
    Replies:
    0
    Views:
    492
    Michael
    May 6, 2006
Loading...

Share This Page