> > > Actually on
> > > the subject of these functions, the ones not defined as class methods,
> > > they could all be shifted into the classes and accessed by typing
> > > 'self.get_module_relative_path()'. Apart from the print statements at
> > > the end of 'unit_test_runner.py', these functions are only accessed by
> > > the other class methods. These may as well be converted to an object
> > > oriented approach.
> >
> > Now that is an interesting question: Should they go in the class? Most
> > probably. However, should they be virtual methods that can be overidden?
> > Almost definitley not in my opinion (overridden methods should always be
> > designed to be so) So I suggest they go in as static methods of the
> > class [this was my plan anyway I just have to get down to trying it]
> > also most of these methods should be private [they are not part of the
> > public interface])
>
> That sounds like a really good setup. By static method, do you mean
> using the @staticmethod function decorator? If so, is there a
> benefit? And by virtual method do you mean a standard class method?
the benefit is that people cant start overriding a static method and
claiming that its an interface that we should be maintaining. Also its good
style when operating in a function where there is no need to use self such
as utility methods. e.g here is a quote from
http://www.rexx.com/~dkuhlman/python_101/python_101.html
snip----------------------
Most of the time, almost always, implement plain instance methods. Implement
an instance method whenever the method needs access to the values that are
specific to the instance or needs to call other methods that have access to
instance specific values. If the method needs self, then you probably need
an instance method.
Implement a class method (1) when the method does not need access to
instance variables and (2) when you do not want to require the caller of the
method to create an instance and (3) when the method needs access to class
variables. A class method may be called on either an instance or the class.
A class method gets the class as a first argument, whether it is called on
the class or the instance. If the method needs access to the class but does
not need self, then think class method.
Implement a static method if you merely want to put the code of the
method> within the scope of the class, perhaps for purposes of organizing
your code,
but the method needs access to neither class nor instance variables (though
you can access class variables through the class itself). A static method
may be called on either an instance or the class. A static method gets
neither the class nor the instance as an argument.unsnip------------------
The information at that link looks quite useful, I should have a read
of it. It should be added to the python-docs package. The use of
private names should prevent people from overwriting the methods. All
the functions of the 'unit_test_runner' module could be turned into
static methods of their respective classes, possibly made private if
they are shifted to the RelaxTestCase base class.
> Making the methods private is ok by me. I haven't used private names,
> but in the situation where someone is adding tests to the test suite -
> this would be quite useful. For sanity, I would use the following
> ordering of the class methods throughout all of relax. First would
> come the special methods 'self.__xxx__()' ordered alphabetically with,
> of course, 'self.__init__()' as the very first method. Then in
> alphabetical order would be the private methods 'self.__xxx()'.
> Finally, and again alphabetically ordered, would be the standard class
> methods.
can I suggest a slightly different order (if this isn't already set in
stone of course, otherwise I will obey ;-)
The only thing that is set in stone is that special methods come first
followed by standard methods, both alphabetically sorted. If you have
a look at the relax sources you'll see that I haven't often used any
of the other categories that you list. For example I use the
self.__init__() function to setup any constants, variables, etc.
constants
variables
special methods
standard instance methods (watch out class methods can mean a different
thing
private variables
private methods
all alphabetically listed
This makes for a logical ordering for the general reader (i.e. anm extrenal
user of the class) as the things any one other that the developer of the
class wants to read come first
The order looks good. I would suggest that the private variables
follow the variables so that all the methods are grouped together. So
for example:
class Test:
a = 1
__b = 2
def __init__(self):
print "Init"
self.c = 3
def test(self):
print "Test"
@staticmethod
def test2():
print "Static test"
def __test(self):
print "Private test"
Is this similar to what you were thinking?
Edward
Re: Re(2): r2860 - /branches/test_suite/test_suite/unit_tests/unit_test_runner.py