large class hierarchies in python

[Alex Martelli]

Justin Dubs wrote:
        ...
> I want the directory structure to be the module (package?) structure of
> the program.  

That's Python's basic package/module infrastructure, after all.

> And I want each class to exist in a file of the same name.

This may be excessive granularity, but that's an issue quite independent 
from package/module issues.

> I haven't yet gotten this concept to mesh well with the python 
> module/import paradigm.  For example:
> 
> /
> /agent
> /agent/Agent.py
> /agent/Environment.py
> /agent/grid
> /agent/grid/GridAgent.py
> /agent/grid/GridEnvironment.py
> 
> Here, GridAgent and GridEnvironment inherit from Agent and Environment,
> respectively.  I assume each directory will need a __init__.py file, but I
> really don't understand what to put in it to have it behave the way I'd
> like.  Any suggestions?

Maybe
        __all__ = ["GridAgent","GridEnvironment"]

as grid/__init__.py, etc, but that's only really needed if you want to 
support "from agent.grid import *" and the like.  If you have no other 
initialization code you want to run for the package, __init__.py may almost 
be empty -- except for the docstring, which should really always be there.
Such tricks as manipulating __path__ are rarely needed.  The essay at
http://www.python.org/doc/essays/packages.html does a creditable job of
presenting such issues, it seems to me.

agent/__init__.py:
"""The agent package enables agentification [snip]"""

agent/Agent.py:
"""The agent.Agent module [blah blah]"""
class Agent:
    """The agent.Agent.Agent class [blah blah]"""
    pass

agent/grid/__init__.py:
"""The agent.grid package enables agentification [snip]"""

agent/grid/GridAgent.py:
"""The agent.grid.GridAgent module [snip]"""
from agent import Agent
class GridAgent(Agent.Agent):
    """The agent.grid.GridAgent.GridAgent class [blah blah]"""
    pass

Etc, etc.


> Also, as a maybe simpler question:
> 
> Is this entire method of programming just not going to work out with
> Python?
> Is Python not suitable for this type of problem?  If not, what languages
> do you know of that are syntactially similar to Python and WOULD be
> appropriate?

I don't know of anything in Python that will stand in the way of this 
approach, nor of any languages where this approach would work better.


Alex