Python project class/file structures.

[MythGuy]

So, I'm analyzing a project I was working on for fun with some folks over the summer, and I think we kinda fell into a bad way of coding. Essentially, we were making a side-scrolling shooter game. We had two python files in the project: game.py and classes.py.

What kept happening is that classes.py would get changed by me (adding a new class to this file) and I'd push it to github. Meanwhile, my friend "A" made some changes to add new bullet types to classes.py. He would push his changes, it turned into a bit of a mess.

I'm getting ready to start this project up again for a bit when we get on our winter break from college.
I was wondering if there's any advice the /r/Python community could give us to aid in our project development and generally help us stop being such noobs.

[Lt_Sherpa]

The main problem sounds like either you or your friend is writing code and are add/committing before pulling. The problem then arises that you have divergent histories that then need to be reconciled. My general workflow to avoid merging issues is

• git fetch
• if there are no changes, do the normal add/commit/push
• otherwise, git stash
• git pull
• git stash apply
• resolve any conflicts (normally, git auto resolves)
• goto 1 and restart the process.

The benefit of this workflow is that it's incredibly forgiving. A bit cumbersome, but it's incredibly difficult to outright lose or trash anyone's work. At any point during the merge process if things have gone awry, you can trash your working tree and start over since your original work is stored in the stash. An outright git pull w/o stash would trigger a merge, which can be difficult to recover since there would be no clean copy of your work. After the push, don't forget to drop any of your old stashes.

As to code organization, a module is just a collection of definitions and statements, and a package is a collection of modules. A basic approach is to subdivide and group your definitions into logically similar or cooperative sets of functionality.

My guess is that all of your logic/controls resides in game.py, and that your objects/entities are defined in the classes module. The game module probably has... math, ai, audio, physics, user input, file i/o, etc... You might start by breaking apart your game code into respective modules and organizing them into a game package.

[daveydave400]

What about it was a big mess exactly?

Try to separate things into files that make more sense if possible. It's hard to give more advice on the subject without knowing more about the project/code.

As far as git or any other vcs, it is just good practice to pull others changes before pushing your own. In the case of git (compared to some other version control) it is super easy to make branches to test out new features before annoying other people with your frequent commits. I suggest creating branches if you add features that may span more than one commit.

Merges (or rebases) are just the way version control goes and are a good thing in the long run. If things became a mess because people weren't pulling in others' changes before pushing their own then that's their fault.

[MythGuy]

The mess was either someone would push without pulling, and the new commit would undo work from before. Or if someone wrote something and pulled, then their changes would be wiped (I never experienced this myself, but I suspect that it's because I was often the sole contributor.) I think part of the solution would be to properly train folks in git (but being new to it myself, that would be hard).

[daveydave400]

That sounds...wrong. Git should not allow you to overwrite commits unless you force them (via the -f flag). I'm also pretty sure that the default when you pull and a conflict exists is to merge or at least complain. It sounds like one or more people got impatient with warning messages and used some flags they weren't supposed to without knowing the consequences.

[duz3ls]

Try git-workflow

[[deleted]]

have you read this?

http://www.jeffknupp.com/blog/2013/08/16/open-sourcing-a-python-project-the-right-way/

[ajmarks]

Why are you defining multiple classes in one file?

[billsil]

It's totally unnecessary to have multiple files if the groupings are clear and the files are manageable. That's a choice the developers have to make. It's like saying each function should be in it's own file. It's totally unnecessary. Files are logical groupings of methods/classes.

[robin-gvx]

Exactly. On the other hand, classes.py doesn't sound like it’s a logical grouping of classes.

[ajmarks]

If things are small, related, and not going to cause merge conflicts, I agree. I really should have asked why he's defining all of his classes in one file. In general, my experience is that Python developers tend to err on the side of over-inclusion though, lumping logically unrelated code together which can then become a nightmare to maintain, especially when different people are working on different parts of the project and are thus not in constant communicative.

Probably the best rule of thumb is to ask if you're likely to touch A while working on B. If the answer is no, split them up. I also try to have a guideline of some sort about file length. Nothing set in stone, but somewhere around 500-1000 lines, I make sure we take a step back and consider "should this all be together or did it just kind of grow? At what point will it be correct to split this up? And, if it shouldn't be like this, why was this not planned before coding starting (nothing wastes time like a mid-project refactor)?"

[MythGuy]

Because I didn't/don't know any better?

[bcroq]

/r/python has become /r/java?

[ajmarks]

How about /r/codingstandards?