Unification of Methods and Functions

David MacQuigg dmq at gain.com
Tue May 25 06:41:02 EDT 2004


On Tue, 25 May 2004 15:31:49 +1200, Greg Ewing
<greg at cosc.canterbury.ac.nz> wrote:

>David MacQuigg wrote:
>> My perspective may be different, because I have not yet absorbed the
>> Python traditions, and I don't have any instictive avoidance of static
>> methods.
>
>Are you coming at this from a Java perspective? In Java
>(and in C++ until recently) you're forced to use static
>methods, because the class is the only kind of namespace
>available.

I studied Java a little bit two years ago, but not enough to absorb
any bias toward static methods.

>But Python has modules for use as general-purpose
>namespaces. Classes are thus relieved of the burden
>of performing this double duty, leaving them free to
>concentrate on what they do best, which is defining
>the behaviour of a collection of objects.

I hesitiate to waste a whole level of packaging on just tying static
methods to their classes.  A distribution of our circuit-design
platform might have a bunch of classes in a module for netlisting.
That module might be part of a complete package for a particular
simulator.  I suppose I could subdivide the module into smaller
packages, but it seems awkward.  Maybe if we could have more than one
module per file.  Files would then be one more level in the packaging
hierarchy.

I still prefer to just add the staticmethod line and leave the method
where I first put it - in the class to which it applies.

>I really recommend that you *use* Python for long
>enough to get a good feel for it, before attempting
>to revise it. Trying to reform something that you
>don't thoroughly understand is fraught with danger.

OK with me.  Looks like there is no rush on Python 3.  In about three
months I should have double the experience with Python I have now.

-- Dave




More information about the Python-list mailing list