Relative-importing *

[rbysamppi at gmail.com]

On Aug 4, 7:10 am, Ben Finney <bignose+hates-s... at benfinney.id.au>
wrote:
> rbygscrse... at gmail.com 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! :)