Help structuring programs

[lgalex]

After reading some tutorials and books, my Python skills are slowly getting better. But one thing all the learning material I used seem to lack is explanations on how to structure bigger programs.
I get that I can use multiple files and import them and all that stuff, but I don't know the "correct" way to do it in bigger programs. If someone knows about a good tutorial or book that covers... program structuring... or something like that, that would be useful.


For example, I use Pygame to build a simple game, and I thought that the code I use to read and process sprite sheets could be in a separate module that I could reuse in multiple places and/or programs. So I thought I could put it in a separate file and import it where I need it.
But I have to import Pygame in that module, because some stuff I do with the sprite sheets needs it. The thing is I also import it in the file where I use my sprite sheet stuff.
So, I have a game file, that imports Pygame and my sprite sheet stuff, and my sprite sheet file also imports Pygame.
It seems that I have to do it in every file, so I wonder if it is really necessary and if it slows down / uses more memory because the game imports it multiple times. Is there a better way to do it?

Same thing with the pygame.init() call... Do I have to do it in every module that uses Pygame? It seems like I do... (well, few things in Pygame actually need it)

I guess that my question is whether it is the right way to do it (reimport Pygame or any module I need, and initialise if needed)? A part of me doesn't like that I do something multiple times for "nothing", simply to split my program in multiple files. But maybe it is ok and python is smart enough not to reload stuff multiple times... or maybe not and it's still the way to do it. I don't know.


So, that's the kind of things I wonder about. I can make it work, but I want to make sure it's the right way. Hopefully someone can explain it to me or point me to a book or tutorial that explains it.

Thanks

[scotty101]

You haven't shared any code so it is difficult to give specific advice.

Python is clever enough that if modules import the same package, python won't try to import it again.

I worked with a few colleagues on a pygame more than 8 years ago now and it used pygame. The main programmer introduced me to python and object oriented programming. It splits the program in to different modules based on the "objects" in the game. For example all the code related to an aircraft, is in the aircraft.py file. Waypoints are in another etc.
https://github.com/scotty3785/python-ai ... ic-control
Not saying that this is a shining example of a game as we were all learning at the time but it does split up the various objects and functions relatively well.

If you haven't done object oriented programming before maybe run through a few tutorials. From my experience it greatly improves the layout and modularity of the code, all the methods and data required by one object in the game are all in a single file imported in to a larger "game" class.

DRY (or Don't Repeat Yourself) is a key term here, if you find yourself writing the same code over and over again, odds are there a more efficient way to do it either with functions or classes.

[lgalex]

You haven't shared any code so it is difficult to give specific advice.

Python is clever enough that if modules import the same package, python won't try to import it again.

Thats what I thought, even though it's counter-intuitive because you actually have to import it everywhere you use it anyway. I guess it's only to tell python you want to use it, not to reimport it again.

I worked with a few colleagues on a pygame more than 8 years ago now and it used pygame. The main programmer introduced me to python and object oriented programming. It splits the program in to different modules based on the "objects" in the game. For example all the code related to an aircraft, is in the aircraft.py file. Waypoints are in another etc.
https://github.com/scotty3785/python-ai ... ic-control
Not saying that this is a shining example of a game as we were all learning at the time but it does split up the various objects and functions relatively well.

If you haven't done object oriented programming before maybe run through a few tutorials. From my experience it greatly improves the layout and modularity of the code, all the methods and data required by one object in the game are all in a single file imported in to a larger "game" class.

DRY (or Don't Repeat Yourself) is a key term here, if you find yourself writing the same code over and over again, odds are there a more efficient way to do it either with functions or classes.

Yeah, that's what I was thinking. I guess I was on the right track I simply want to be sure that I do things the right way before I move on to other aspects. This is the hard part of learning something by yourself... it's easy to do something wrong without realizing it.

Thanks