On Aug 4, 7:10 am, Ben Finney <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] writes: > > Yes, I'mimporting* for a reason, a good one, I think. > > Reading your description, I must say I don't see a good reason. > > > I have a set of modules (the number planned to reach about 400) that > > would be dynamically loaded by my program as needed, and they're > > somewhat similar to each other. I wish each of them to import * from > > a certain "parent" module, so that they'll receive whatever > > functions and variables I want all of them to share (using the > > parent module's __all__), which may be overrided by the "child" > > modules at their discretion. Sort of like class inheritance, but I'm > > not doing that because implementing that would be a lot more tedious > > and less elegant. > > It seems to me, based only on this description, that class inheritance > would be far *more* elegant, and much easier to follow when reading > the code. > > If all these functions and other objects are so closely-related that > they form the core of some inheritance-like system, what's so > inelegant about wrapping them in a class so that the inheritance is > explicit in the module where it happens? > > -- > \ "The only tyrant I accept in this world is the still voice | > `\ within." -- Mahatma Gandhi | > _o__) | > Ben Finney
Remember that I'm a relative beginner at Python, and actually programming in general, so forgive me if what seems obvious is opaque to me. This project's my way of learning the language. :) I tried a class-based system. The reasons why I would prefer using modules only rather than classes in modules was because I think that it's a little redundant, and this redundancy made it more difficult to grapple with the module/classes' names. This system is for implementing "moves" in a game, of which there will eventually be about 500 when all are implemented. I decided to try to implement each move in a separate module, so we could add and maintain moves to the system at convenience instead of editing a single huge module with hundreds of classes. (Each move is completely separate and unrelated to each other, other than the fact that they share a few variables. In addition, I plan to make it possible to have a user add new move modules at their discretion as extensions to the game.) However, this ended up with a system where every single module had a single class representing the move in it. The name of the class and module have to be the same so that dynamic importing is possible, but the repetition of the name is undesirable, as it increases the chance of errors that might be hard to diagnose. (Because I'm planning to have it possible for a hypothetical user to create his/her own modules, I care a lot about making it as simple as possible.) (In addition, it probably would make the program somewhat slower to have an internal class inside every module, and performance is important to me, as I'm planning to use this project in a future game. These modules are not going to have full-fledged object construction and so forth. I don't want to construct and use objects at all--it seems like a waste of time and memory to me to inherit __new__, __del__, and so on. All that I want these modules to do is to encapsulate varying information and behavior for /other/ objects to use.) It's not a matter of life-and-death for me if I have to use class inheritance. But I think it would suboptimal. But regardless of if it's the "right thing to do", do you all think it's an unintended bug? Thanks again! :) -- http://mail.python.org/mailman/listinfo/python-list