On Tue, 24 Jan 2012 19:54:24 -0800, lh wrote:
> Is this possible please? I have done some searching but it is hard to
> narrow down Google searches to this question. What I would like to do
> is, for example:
> 1) define a class Foo in file test.py... give it some methods
> 2) define a file test2.py which contains a set of methods that are
> methods of class Foo defined in test.py.
Technically, yes, this is possible, but you shouldn't need to do it.
Needing to split a single class across multiple files is a sign of bad
design. If the class is that huge, then it probably does too many things
and should be broken up into multiple classes and then reassembled using
composition.
[...]
> In short I would like to distribute code for one class across multiple
> files so a given file doesn't get ridiculously long.
What do you call "ridiculously long"?
One of the largest modules in the Python standard library is decimal. I
consider decimal to be about as big as a single module should get: over
5000 lines of code. Any larger, and you should consider splitting it into
a package with multiple files.
But note that those 5000 lines include over 500 lines of comments,
details documentation, plenty of blank lines, 14 public classes, 3 public
functions, and at least 17 private functions or classes. The main class,
decimal.Decimal, is about 2800 lines of code.
If your class is smaller than that, I don't think you need to worry about
splitting it.
But let's suppose you really do have a good reason to split the class
into multiple files. And not just "because that's how I'd do it in Java".
Suppose you have a class Spam, and it has two methods, spam() and eggs().
You want to split the methods into different files. (Perhaps you want to
win a bet.) There are three main possibilities:
(1) Inheritance.
(2) Composition or delegation.
(3) Dynamic code injection.
Let's start with inheritance.
In module a.py, create a class:
class EggMixin:
def eggs(self):
c = self.colour
print("%s eggs go well with %s spam" % (c, c))
Notice that as a mixin, EggsMixin isn't required to provide the
self.colour attribute.
Technically it isn't necessary for this to be a mixin, but it is probably
the best design.
Now in module main.py, create the Spam class you really want, using
multiple inheritance to inherit from the "real" superclass and the mixin:
import a
class Spam(SpamParent, a.EggMixin):
def __init__(self, colour='green'):
print("Spam spam spam LOVELY SPAM!!!")
self.colour = colour
def spam(self, n):
return "spam!"*n
By the way, SpamParent is optional. If you don't need it, just leave it
out.
Now, on to composition. First, let's redesign the egg class in a.py:
class Egg:
def __init__(self, owner):
self.owner = owner
def eggs(self):
c = self.owner.colour
print("%s eggs go well with %s spam" % (c, c))
And in main.py:
import a
class Spam(object):
def __init__(self, colour='green'):
print("Spam spam spam LOVELY SPAM!!!")
self.colour = colour
# Create an Egg that has this Spam instance as the owner.
egg = a.Egg(owner=self)
# And store it for later use.
self._egg = egg
def spam(self, n):
return "spam!"*n
def eggs(self):
# Delegate to the saved egg.
return self._egg.eggs()
Last but not least, lets try dynamic code injection. In a.py, create a
function using a placeholder self parameter:
def eggs(self):
c = self.colour
print("%s eggs go well with %s spam" % (c, c))
And here is your main module:
import a
class Spam(object):
def __init__(self, colour='green'):
print("Spam spam spam LOVELY SPAM!!!")
self.colour = colour
def spam(self, n):
return "spam!"*n
# Add the extra method that we want.
Spam.eggs = a.eggs
So now you have three ways of doing something that shouldn't be done :)
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
