[Tutor] Need to be pointed in the right direction for file organisation.

[Mac Ryan]

Thank you Alan for the prompt reply,


> - Put reusable components into modules.

	OK: the use of files as "libraries" is quite clear to me and indeed I
am already doing that. What is not clear is if I should _only_ put in
modules stuff that is reusable, or if there are other widely accepted
ways to user files.
	For example, in the GTK application I am currently developing I have a
notebook widget (sort of tabbed windows which are visible only one at a
time). I was therefore thinking about separating the classes for each
"tabbed window" in different files, under the impression that this would
make the program faster / with a smaller memory footprint, as only the
needed file will be loaded into memory [In PHP you can reach quite a
gain in terms of speed if yo do so].
	Would this be considered a proper way to code in python?

	Another concern of mine was the readability of the source code, and I
was wondering indeed if there was a "pythonic style" that was commonly
understood as "the right one" [I'm thinking to those kind of guidelines
like "put the import directive at the top of the file", but for file
organisation]

> - Build modules "bottom up" so that depenedencies tend to 
>   go one way, with higher level modules importing lower level ones.

I'm not sure I got it completely, does this mean that the file structure
should be a hint of how dependency works, with ancestors nested in the
subfolders of the children classes or something similar?

Anyhow, thanks a lot for having answered so promptly! :)

Mac.

> > While I am working my way up to a more pythonic and cleaner style in
> > the code, one thing that I have very confused ideas about is how I
> > should organise my code, in terms of classes and files.
> 
> I don't think there is any definitive answer.
> 
> - Put reusable components into modules.
> 
> - Don't necessarily create a module per class, but rather gather 
>   related classes into a single module.
> 
> - Build modules "bottom up" so that depenedencies tend to 
>   go one way, with higher level modules importing lower level ones.
>