glass icon indicating copy to clipboard operation
glass copied to clipboard

Functions in `glass` module

Open ntessore opened this issue 2 years ago • 2 comments

Make all public GLASS functionality under the glass module name.

This needs a new structure for the documentation, and is therefore a bigger task than just importing the modules into glass/__init__.py.

ntessore avatar Jun 14 '23 14:06 ntessore

Hi @ntessore , as you mention, it is straightforward to import into init.py - I don't understand the issue on documentation - "Import glass" as well as the existing "Import glass.module" will work in the test cases and examples so documentation could remain the same, because the full path can still be used in the imports.

ucapbba avatar Feb 06 '24 09:02 ucapbba

the full path can still be used in the imports

That's right, but there should only be one canonical path for each object. Once we import everything into the top-level module, then everything should be documented as accessing the symbols from glass. The submodules would effectively become an implementation detail to organise the code.

Once everything is in the top-level module, I think we should always use functions with the module prefix, e.g. glass.partition() instead of from glass import partition; partition().

But, as you point out, the full path can still be used, so we would not break anyone's code :)

ntessore avatar Feb 06 '24 09:02 ntessore

It will also be useful to add the __all__ variable in every module to differentiate public and private API.

Another thing to discuss - the repository has relative imports everywhere at the moment, but PEP8 recommends using absolute imports wherever possible -

Absolute imports are recommended, as they are usually more readable and tend to be better behaved (or at least give better error messages) if the import system is incorrectly configured (such as when a directory inside a package ends up on sys.path) ... However, explicit relative imports are an acceptable alternative to absolute imports, especially when dealing with complex package layouts where using absolute imports would be unnecessarily verbose

All of these issues are interconnected, but please let me know if they should be separate issues on the tracker.

Saransh-cpp avatar Sep 16 '24 11:09 Saransh-cpp

Also, glass.core is not documented in the API reference. Is it only supposed to be used internally and not by the users directly?

Saransh-cpp avatar Sep 16 '24 12:09 Saransh-cpp

It will also be useful to add the __all__ variable in every module to differentiate public and private API.

Indeed, although if only the main glass namespace contains public API going forward, we probably don't need to have __all__ in every module.

Another thing to discuss - the repository has relative imports everywhere at the moment, but PEP8 recommends using absolute imports wherever possible -

This is mostly a holdover from when GLASS was more modular and namespace-based. We can get rid of the relative imports.

All of these issues are interconnected, but please let me know if they should be separate issues on the tracker.

This issue seems as good a place as any to discuss.

Also, glass.core is not documented in the API reference. Is it only supposed to be used internally and not by the users directly?

Correct, it contains functions which are not user-facing. It should probably become part of the developer documentation (#185).

ntessore avatar Sep 16 '24 12:09 ntessore

All of these issues are interconnected, but please let me know if they should be separate issues on the tracker.

I think it would be good to have, say a checklist in this issue, so this one is "finished" when all the others have been ticked off

paddyroddy avatar Sep 17 '24 11:09 paddyroddy