Public and Internal Interfaces about pykale HOT 5 CLOSED

@sz144 Many thanks. It is great that you bring up this issue. It will be an important change/enhancement so we'd better consult more references to decide what is the best (i.e. modern and professional) approach for us and discuss in a pykale meeting to make a decision and implement.

Since we are aiming for the pytorch ecosystem, we should consult recent libraries there more (e.g. those at the bottom of the contributing guidelines). For example, utils is common for almost all libraries so we could compare how they implement that. We can have some initial discussions when we meet.

from pykale.

@sz144 I've studied further. Wildcard import from ... import * is now considered as a bad practice and we should NOT use it. Therefore, defining __all__ is no longer useful, right?

I know some other code did it but those may be due to historical reasons (older version of python) are now considered as bad practice by modern python, as least according to what I found out. Note that we requires python 3.6+.

from pykale.

@sz144

This is from a card created by @sz144

References:
https://www.python.org/dev/peps/pep-0008/#public-and-internal-interfaces

https://stackoverflow.com/questions/35727134/module-imports-and-init-py-in-python

This post is from 5 years ago about python 2.7 so it is quite outdated.

Examples:

• pytorch
• scikit-learn
• tensorly

These packages were build years ago so its practice may not be the best practices for more recent python.

from pykale.

@sz144 I've studied further. Wildcard import from ... import * is now considered as a bad practice and we should NOT use it. Therefore, defining __all__ is no longer useful, right?

I know some other code did it but those may be due to historical reasons (older version of python) are now considered as bad practice by modern python, as least according to what I found out. Note that we requires python 3.6+.

from ... import * is a bad practice but defining __all__ should still be useful. Let me check more references.

from pykale.

If a convincing reason can be found before the next pykale meeting, we could consider. Otherwise, we need to move on via PR #101.

from pykale.