Question about the signal module and the _signal subpackage

[jan-car]

While working on new signal subclasses for electron holography in #1058 I started wondering, why HyperSpy has a "private" subpackage hyperspy._signals, as well as a module hyperspy.signals.py which, in my opinion, looks exactly what the hyperspy._signals.__init__.py of an open hyperspy.signals-subpackage should look like (currently the __init__.py is empty).

Would'nt it be more intuitive to rename the hyperspy._signals subpackage to hyperspy.signals and to transfer the code from hyperspy.signals.py to hyperspy.signals.__init__.py?

Furthermore the current hyperspy.signal.py (singular) module which contains the basic Signal class (I'm not sure if this is still the case in the restructured 0.8.x branch, it should be BaseSignal there) could also be moved into this subpackage where it structurally would belong.

I can imagine that the reason is that with an open hyperspy.signals subpackage the user will see not only the different signal subclasses, but also the modules where they are defined.

Typing hs.signals. for example will have autocomplete options for

hs.signals.image
hs.signals.Image
hs.signals.spectrum
hs.signals.Spectrum
etc...

cluttering the namespace (which seems to be generally unwanted as seen in #1059). I have this problem in a private project, too. Is the current structure with a hyperspy.signals.py "proxy"-module the only way around that? I know that you can define an __all__ variable in a packages __init__.py, but sadly that only defines what gets imported with

from mypackage import *

Maybe making all modules in the hyperspy.signals subpackage "semi-private" by renaming them to have an underscore in front would solve this problem somewhat (they at least would appear at the end of the suggestion list), but this would maybe mean a lot of renaming in HyperSpy overall...

I ask this mainly out of my interest in package design, maybe there is something fundamental that I'm missing.

[francisco-dlp]

You've answered your own question.

Regarding if there is another way to do that, the answer is yes: we could overload the __dir__ method of the signals\__init__.py module so that it only returns the classes, not the modules. That would be much neater!

[jan-car]

Overwriting __dict__ seems like a very elegant solution, indeed. I looked around a lot for this (as I said, I could use this in a private project, too), but it appears that overwriting the __dict__()-method can only be used for objects. Even for the class of the object it will not work...

dir(MyClass(some_parameter)) will use the overwritten __dir__ function, invoking dir(MyClass) just lists the attributes without regard for the custom __dir__.
For methods and packages I found even less encouraging information, at least for me, defining a __dir__()-method on the module level didn't do anything.

If no one else has any input, should I just close the issue then?

At least I learned a bit more about some Python magic, thanks for the input :-)!