Best way to handle changing list of class imports

[Dave Angel]

Scott Grant wrote:
> On Oct 10, 2:42 pm, "Diez B. Roggisch" <de... at nospam.web.de> wrote:
>   
>> Scott Grant schrieb:
>>
>>
>>
>>     
>>> Hi there,
>>>       
>>> I'd like to set up a framework in which I can add or remove new
>>> classes of a given expected subclass to my package, and have the
>>> system load that set at runtime and be able to use them.  In essence,
>>> if I have a class X, and subclasses A, B, and C that derive from X,
>>> what's the most pythonic way to allow me to add or remove A, B, or C
>>> from the package before runtime, to iterate over all known imported
>>> classes that inherit from X, while minimizing the modifications to my
>>> existing program.
>>>       
>>> Is the best way to set up a directory in my package for these classes,
>>> and to define the list of active imports in the __all__ list in
>>> __init__.py?  Or is there a better way?
>>>       
>>> For detail, I'm writing a system that students will be able to submit
>>> game strategies that will compete against each other in a framework
>>> that passes them game state and expects moves in return.  It would be
>>> great to be able to add or remove these player strategies as new ones
>>> come in, but I don't want to add a bunch of overhead importing each
>>> one specifically in the game manager itself.
>>>       
>> I think you re-think your approach and kind of invert it. Instead of
>> viewing your system as game-strategies plugged into the framework, make
>> a game-strategy *use* your framework.
>>
>> Thus what your students deliver must be an executable script that sets
>> up the game, and then passes the own strategy into it.
>>
>> Diez
>>     
>
> Part of the benefit of the original approach (and the main reason I
> want to use it that way) is that in multi-player or competitive games,
> these strategies should be able to compete against each other.  It it
> was a rock-paper-scissors system, I'd like strategy A to compete
> against strategy B, and with large sets of strategies, to allow my
> system to set up a crosstable with the minimal amount of hardcoding.
> I'd like to know which strategy is best by setting up a competition
> against all other submissions.
>
>   
I understand your goal to have several (or all) of the students' 
strategy files present, and competing.  But I have to ask whether you 
wouldn't be better off launching each student in a separate process (or 
separate machine, even), and competing over sockets or somesuch.  Two 
reasons come to mind:  1) students have a way of working *around* a 
problem, and sabotage (intended or not) is a definite possibility.  2) 
scalability to larger numbers of strategies.

But I'll assume you've already considered and dismissed this kind of 
approach.  So essentially you're building an extensible framework, where 
parts of it are "discovered" at load time, and automatically merged in.

For that, I'd suggest reserving a directory at a known location, doing 
an os.path.dirname() on that directory, and building a list of module 
names.  Then use __import__() to load them, and build a list of module 
objects, and a list of classes in those modules.  Suggest classname to 
be simply formed by uppercasing the first letter of the module file.

DaveA