search

PyAOS / aoslib

A collection of standard atmospheric and oceanic sciences routines.
45 stars 32 forks source link

Sub-module organization #4

Open jwblin opened 11 years ago

jwblin commented 11 years ago

David mentioned: "Another possibility is that functions from particular sources should be contained in sub-modules, e.g. aos.awips. However, this option would probably get in the way of grouping the codes that are related in functionality."

Here's an initial thought I have about this. How about creating sub-module groupings that relate to code structure rather than functionality but importing and assigning the functions in sub-modules at the module level. Thus, while the foo function may be in the module submod, in the init.py or aoslib.py file there would be a line import submod.foo as foo. This way, new users would have access to all the package's functions in the package without having to import sub-modules. Thoughts?

david-ian-brown commented 11 years ago

This seems like an excellent idea to me.

david-ian-brown commented 11 years ago

I think this is a great idea. -dave

On Feb 15, 2013, at 10:16 PM, Johnny Lin wrote:

David mentioned: "Another possibility is that functions from particular sources should be contained in sub-modules, e.g. aos.awips. However, this option would probably get in the way of grouping the codes that are related in functionality."

Here's an initial thought I have about this. How about creating sub-module groupings that relate to code structure rather than functionality but importing and assigning the functions in sub-modules at the module level. Thus, while the foo function may be in the module submod, in the init.py or aoslib.py file there would be a line import submod.foo as foo. This way, new users would have access to all the package's functions in the package without having to import sub-modules. Thoughts?

— Reply to this email directly or view it on GitHub.

jjhelmus commented 11 years ago

This is a good idea as long as no sub modules have conflicting function names (ie submod1.foo and submod2.foo which would be imported as foo). We can avoid this by enforcing that all function names must be unique, but then we might as well have a flat namespace. I think we can deal with conflicting function names when then come up, and having a more organized namespace behind the scenes with make resolving these conflicts much easier.

doutriaux1 commented 11 years ago

I think keeping it in submodules is preferable. We could end up with a huge package (trust me I know about these...) and some subcomponent might not build on all system. I think having separate module allows more flexibility for the end user. We should also make sure the install script has options to enable/disable each indiviudual submodule. Again, and especially since we're dealing with FORTRAN, we face a high chance of having some components not build, so modularity seems (to me) to be key.

jwblin commented 11 years ago

Part of my thinking in using submodules for the code and making all (or at least the core) functions available at the package level is that new users will want to access the functions without reference to finding the one they want in a submodule. The model I'm thinking of is how nearly all the core functions of NumPy are available at the top package level as well as how pylab contains nearly all the core plotting functions of matplotlib. The NumPy and pylab functionality makes those packages more accessible to new users and newbie users.

With regards to install, I think users should be able to customize an install as they see fit, but I think the default should be to install everything and that we not add a submodule that is not tested to install properly on all major platforms (OS X, Win, Linux) and versions of Python that we'll support (say, 2.6 or 2.7 and higher). That is to say, I think it's more important that all the submodules we have work on all reasonably probable installs rather than that we include all the submodules that would possibly be of interest. Another way to put it is that I think this package should be focused on providing core, commonly used functionality rather than including the capabilities of all possible candidate functions. For those interested in non-core functions whose builds are dicey, they should install those submodules separately themselves and work through the install issues themselves.

doutriaux1 commented 11 years ago

We can still do that bring up all the submodules function back at the top level. I'm fine with this, I was more thinking along the lines of build error, giving the end-user the possibility of turning off failing parts is crucial in my opinion.