[Nipy-devel] [nipype] Semantics [was] Naming convention for FSL interfaces
Wed Jan 27 17:10:31 CST 2010
On Wed, Jan 27, 2010 at 9:01 AM, Satrajit Ghosh <firstname.lastname@example.org> wrote:
> i took chris' email to address some semantics issues. i think this is a
> general aspect that we will need to address soon and perhaps with a sprint.
> i believe this is also what dav was referring to in regard to the interfaces
Great point Chris, thanks for bringing it up. I think this is a
perfect thing to sprint on. We discussed having a few sprints before
our next release, lets have one next week. Actually, how about having
one each week for the next three weeks and we'll release mid-February?
I know schedules are busy, if we have three sprints, hopefully we can
schedule them so that everyone can participate for a few hours on at
least one sprint. If developers agree I'll share the nipy google
calendar and work out a schedule?
Some items to sprint on:
- class and functions names conform to PEP008 standards.
- better test coverage
- documentation, fix current build warnings, improve docs in general
- bug fixes, close some tickets
Basically, no new functionality, but some thorough cleaning and
improved code quality in general.
> 1. other than following Python conventions, i would also like to note that
> FSLsmooth and FSLmath are sort of redundant when we say:
> from fsl import FSLmath or fsl.FSLmath. i would like to get rid of FSL
> altogether. a lot of this is historical and part of the tussle here is that
> we would like to reflect underlying command and i/o names of the interface
> (e.g., fslsplit, fslroi) and we often fall prey to using their terms even
> when there may not be a good reason. i think we have a sufficient bulk of
> functionality now that we should start being consistent with every new
> function we add.
+1 on conforming with the Python naming conventions.
> 2. invol, infile(s), smoothedimages, outvol, outfile - we have every
> possible naming convention there is for input and output parameters. we
> should settle this as well (soon). we need to keep in mind that nipype will
> support in memory computations (in the future) as well as file-based
> here is a suggested grammar for naming convention
> name is : specific (e.g., label, mask, ...) or general (e.g., vol, surf,
> txt, ...)
> type is : file(s), obj, func, list, arr, mesh, int, float, bool, str
> i think 'type' may be useful, but the added verbosity may not be necessary.
> (agnostic to its inclusion)
I think having a naming convention is good, but I'd prefer a more
general then specific convention. If we start defining variable names
with a lot of type information I believe the code will become harder
to read. At least that was my experience with Hungarian Notation.
The docstring is the appropriate place for the type information.
I like the practicality of the Linux Kernel naming convention:
> 3. breaking down fsl.py and other interfaces into sub packages. we've gotten
> to a stage, where some interfaces are really long files and become difficult
> to navigate. i would be in favor of breaking these down into sub-packages
> and export all of their interfaces to the top interface level.
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
More information about the Nipy-devel