[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[pygame] separating pygame dependent code from general code
Hi
In a library, how would pygame dependent code be separated from general
code?
Let's say that I write a package named 'mygamepack'. In that package
there are some modules that are only dependent on python (general parts)
and there are some others using pygame (lib dependent parts). How would
that package be split up, so that the general parts could be used by
other libraries without adding the pygame dependent parts? I wonder if
there is a general way of doing this.
Here are some ideas (as a file layout) how to split it up:
Option 1:
mygamepack
+-module1.py # general part
+-module2.py # general part
+-module1pygame.py # lib part, dependent on pygame
+-module2pygame.py # lib part, dependent on pygame
+-module1otherlib.py # lib part, dependent on otherlib
+-module2otherlib.py # lib part, dependent on otherlib
Pros:
-all code in one package, imports are no problem
Cons:
-each supported lib adds bulk and overhead
-separation is not that clean
or split it on package level:
Option 2:
mygamepack
+-module1.py # general part
+-module2.py # general part
mygamepackpygame # imports mygamepack!
+-module1.py # lib part, dependent on pygame
+-module2.py # lib part, dependent on pygame
mygamepackotherlib # imports mygamepack!
+-module1.py # lib part, dependent on otherlib
+-module2.py # lib part, dependent on otherlib
usage if using it in a skellington:
mygame
+-data
+-gamelib
+-mygamepackpygame # local copy, importing
mygamepack using relative imports
+-mygamepack # local copy
Pros:
-clearly separates the general from lib dependent code
Cons:
-if packages are not on pythonpath or site-packages, need to
import general lib relatively
Maybe there are other pros and cons I didn't think of!
Thanks for your opinions and suggestions.
~DR0ID