change tool_methods.py name to something more reasonable

[madscatt]

build_methods? I dislike the name_of_module/name_of_module.py bit sometimes, but perhaps build_utilities.py will suffice.

Feedback?

[StevenCHowell]

can you give an example? Like sasmol/sasmol.py? or monte_carlo/monte_carlo.py?

[madscatt]

import sasmol.sasmol as sasmol

has changed (in zazmol that is) to

import sasmol.system as system

When importing if the main module (i.e. package in site-packages) if the name of the package matches the name of the file in the package the import can be confusing at stages of development, deployment and training.

That said, I haven't ran across a standard way to handle this. It would help if we pick a rule and stick with it.

[StevenCHowell]

Consider reviewing the PEP 8 and PEP 423 standards. They should be a good starting point, if not fully sufficient.

one pertinent bit from PEP 8:

Package and Module Names

Modules should have short, all-lowercase names. Underscores can be used in the module name if it improves readability. Python packages should also have short, all-lowercase names, although the use of underscores is discouraged.

When an extension module written in C or C++ has an accompanying Python module that provides a higher level (e.g. more object oriented) interface, the C/C++ module has a leading underscore (e.g. _socket ).

some bits from PEP 423:

Ownership could be:

• an individual. Example: gp.fileupload [7] is owned and maintained by Gael Pasgrimaud.
• an organization. Examples:
  • zest.releaser [8] is owned and maintained by Zest Software.
  • Django [9] is owned and maintained by the Django Software Fundation.
  • a group or community. Example: sphinx [10] is maintained by developers of the Sphinx project, not only by its author, Georg Brandl.

• a group or community related to another package. Example: collective.recaptcha [12] is owned by its author: David Glick, Groundwire. But the "collective" namespace is owned by Plone community.

  Avoid deep nesting

The Zen of Python [25] says "Flat is better than nested". Two levels is almost always enough

Don't define everything in deeply nested hierarchies: you will end up with projects and packages like "pythonsport.common.maps.forest". This type of name is both verbose and cumbersome (e.g. if you have many imports from the package).

Furthermore, big hierarchies tend to break down over time as the boundaries between different packages blur.

The consensus is that two levels of nesting are preferred.

For example, we have plone.principalsource instead of plone.source.principal or something like that. The name is shorter, the package structure is simpler, and there would be very little to gain from having three levels of nesting here. It would be impractical to try to put all "core Plone" sources (a source is kind of vocabulary) into the plone.source.* namespace, in part because some sources are part of other packages, and in part because sources already exist in other places. Had we made a new namespace, it would be inconsistently used from the start.

Yes: "pyranha"

Yes: "pythonsport.climbing"

Yes: "pythonsport.forestmap"

No: "pythonsport.maps.forest"

Top-level namespace relates to code ownership

This helps avoid clashes between project names.

[madscatt]

changed the name to build_methods.py