Any Python programmers in here?

[Marcel]

I've taken my hand to Python.
So far I've cobbled together a project I'm working on. Basically it's a wage calculator which will be tailored and very specific to me.
It will eventually take regular input of shift times, and will calculate an exact expected wage based on those times, pay periods, my own pay rate, my employer's pay rules (regarding rounding up/down times etc).

At the moment it's functional (to a fashion). It has a main GUI, a data file, it loads, sorts, and edits the data (resaving it is next), and some calculations on that data.
Before I go any further, I want to structure it properly (so I'm not doing too much refactoring later on).
I've tried reading up on proper Python structure, with packages and modules and it's just got me confused.

At the moment, there's pretty much one main wagecalc.py file which holds all the methods, classes and class methods.
It imports the following modules : ttk, tkinter, datetime and a couple of others.
The application itself is a class.
Here is a snippet of wagecalc.py

class App(object):
    root=tkinter.Tk()
    ...
    ....


def main():
    wage_calculator = App()
    os.system('''/usr/bin/osascript -e 'tell app "Finder" to set frontmost of process "Python" to true' ''')
    wage_calculator.root.mainloop()
    try:
        wage_calculator.root.destroy()
    except:
        pass

if __name__=='__main__;:
    main()

In this same file we have my own created gui classes (based off tkinter widgets), the gui event callbacks etc.
Also the data manipulation methods, sorting, editing etc.
Also the file loading method too, and the app options.

My question is how should I split this code up using packages and modules? In a general sense. I know I can do it pretty much any way I like, but I'd like to do it properly.....pythonic if you like (especially to save issues later on).

Would things like all the GUI objects go in one file. What about the callbacks for events on those objects? (When a button is pressed etc). Same file? Different one?

Hope I've not rambled on too much. I wouldn't dare post this sort of question on stackexchange, they tear you a new one on there!

BTW, yes, I'm googling a lot of this stuff as I go along, it's how I learn.

 

[DorsetDude]

(One) General theory for this sort of stuff is presentation layer, business logic layer, data access layer. Presentation layer is your GUI objects. The "clicks" etc on there call classes in your business layer, where calculations etc are done and data returned to presentation layer. Any data stored between sessions as it were is saved/loaded by the data access layer being called by the business layer. Quite often the data access layer talks to a database but it neednt be for a simple app.
Entire books have been written on coming up with classes. Each class should have one responsibility is a reasonable rule. e.g one class for writing and reading any data you need.
For GUI objects I would be tempted to have one file per screen shown.

 

[Marcel]

Thanks.
That's the MVC approach isn't it? I'm planning it with that approach in mind.
Since posting this, I've got some sort of structure in place now, based off official guides.
The only thing is, now I've split it up, the code doesn't work. A model isn't getting passed to one place, and there are methods that aren't accessible to a model. There's a circular reference which I need to deal with too. It's not impossible though

 

[DorsetDude]

MVC is a lot more complicated with event firing and all sorts going on. Multi-tier what Ive described. If you are finding your objects dont fit neatly into the design you've chosen it usually an indication that the design isnt suitable. So you end up doing workarounds and cheating and making the whole thing more and more interdependent and complicated and difficult to maintain. If I were you Id probably do it all in excel and tweak it with VBA macros where needed. Good luck anyway!