On Oct 10, 6:44 pm, Dave Angel <da...@ieee.org> wrote: > Scott Grant wrote: > > On Oct 10, 2:42 pm, "Diez B. Roggisch" <de...@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.
That's it, in a nutshell. Instead of having some sort of scripting language to author these strategies, it would be swell to just use the native Python code. Back in the day, I wrote a chess client that competed over the telnet sessions at freechess.org, and that was a really nice way to test out the code. However, the drawback was that I obviously couldn't get a full crosstable of my code versus every other competitor on the network. In this case, I'd like to just set each opponent up against every other, run n times, and see what the overall results are. Doing this locally (and additionally, allowing the competitors to test their results locally for themselves) is a really exciting prospect. > 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. Wonderful, I'll also take a look at this solution. Thanks! -- http://mail.python.org/mailman/listinfo/python-list