provide logging messages for normal operations/actions happening beyound the curtain about nibabel HOT 5 OPEN

Yo. Yes, sorry, the error level was not properly plumbed in, bugfix coming. The log_level doesn't attach to anything, I'm going to remove it. The logger.level is a standard python logger.level, so 0 means 'not set, use default' (which is usually 30) - set to 1 for maximum messages.

from nibabel.

Oh - but reading your email, you wanted messages during ordinary operation like 'adding 2 and 2 to get total of 4, storing in variable "result"' type thing? The logging only happens for fixing header inconsistencies. You could obviously drop logging decorators on the functions you were interested in, but to put logging stuff all over the code seems like it would make it slower and harder to read.

from nibabel.

yes -- sorry for not making it clear -- I wanted logging of the basic operations performed. Not really '1+1=2' type, but more of

> vol = nib.load('file.nii.gz')
Loading Nifti1Header from file.nii.gz
 Verifying the header
  ...... here warnings might come .....
> h = vol.get_header()
Constructed a copy of the header
> qform = h.get_qform()
Computing qform
> vol.to_filename('file2.nii.gz')
Loading data from file.nii.gz
 Loading 10x10x10x1000 volume of dtype=int16
 Scaling data using scale=0.3 and interc=0. into dtype=float32
Storing header into file2.nii.gz
Storing data into file2.nii.gz
 Quantizing data using scale=0.3 and interc=0. into dtype=int16

Something like that.
I might be wrong in the above sequence of events (since I am not sure now what it is), and I space-indented according to the level (our practice in pymvpa's logger), although I guess it will not be the case with default Python logger especially since you have quite high levels for some messages, thus indenting them that far might be too much ;-)
Also because warnings and errors are already at higher levels, this detailed information about actions should probably at even higher levels

If messages are just strings with not much of '%s' and '%r' it should not cause significant slowdown -- majority of time would be taken by logic and I/O. But, additionally, you could make them printed out only in debug mode.

In PyMVPA we have lots of "debug" messages "printed" this way and I do not think we incured much of slowdown -- I could check what is the run time with -O vs without if you like

from nibabel.

Hrrm - that seems like there'd be a lot of logging. Is it the scalefactor in particular that you wanted logged?

from nibabel.

Well -- those were just concrete examples of what relevant issues I ran into recently... for others there could be others. And I think controllable "a lot" is much better than "none". Moreover such debug output could be of great help to the developers of 3rd party software using nibabel as the backend, so those messages, if log level set appropriate, would become a part of bigger "picture" possibly shining the light on the possible underlying problem without getting into pdb

from nibabel.