Skip to content

Instantly share code, notes, and snippets.

@FrankyCTY

FrankyCTY/exporting_modules_functions_from_python_init.md

Forked from CMCDragonkai/exporting_modules_functions_from_python_init.md
Created April 13, 2023 11:32
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save FrankyCTY/e8ef06e68b2df34fc8e7f35cdaa0b19a to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save FrankyCTY/e8ef06e68b2df34fc8e7f35cdaa0b19a to your computer and use it in GitHub Desktop.
Download ZIP

Revisions

  1. @CMCDragonkai CMCDragonkai revised this gist Apr 26, 2018. 1 changed file with 8 additions and 1 deletion.
    9 changes: 8 additions & 1 deletion exporting_modules_functions_from_python_init.md
    View file
    Original file line number Diff line number Diff line change
    @@ -37,4 +37,11 @@ anything that isn't exported here is hidden. Unless the user really wants to
    acquire it, in which case they can explicitly use the module.

    To actually have encapsulation at the module level. You need to use `_` prefix
    on your bindings. This is different from `__` used in classes. See: https://stackoverflow.com/a/1547160/582917
    on your bindings. This is different from `__` prefix used in classes. Note that
    using the `*` import will ignore module bindings that have `_` prefixed. But
    they can still be accessed explicitly if the module is directly accessed.
    See: https://stackoverflow.com/a/1547160/582917

    I think this form of using `__init__.py` is the best way. Users shouldn't need
    to use the `from ... import` syntax unless they need to import specific bindings
    and don't want to use qualified modules.
  2. @CMCDragonkai CMCDragonkai revised this gist Apr 26, 2018. 1 changed file with 7 additions and 1 deletion.
    8 changes: 7 additions & 1 deletion exporting_modules_functions_from_python_init.md
    View file
    Original file line number Diff line number Diff line change
    @@ -31,4 +31,10 @@ from .mod import *
    ```

    Therefore the `__init__.py` is kind of like an exporting script for the package.
    Similar to how I use `index.js` in my JavaScript packages.
    Similar to how I use `index.js` in my JavaScript packages. This means you can
    use the package `__init__.py` as a sort of staging point for all exports. And
    anything that isn't exported here is hidden. Unless the user really wants to
    acquire it, in which case they can explicitly use the module.

    To actually have encapsulation at the module level. You need to use `_` prefix
    on your bindings. This is different from `__` used in classes. See: https://stackoverflow.com/a/1547160/582917
  3. @CMCDragonkai CMCDragonkai created this gist Apr 26, 2018.
    34 changes: 34 additions & 0 deletions exporting_modules_functions_from_python_init.md
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,34 @@
    # Exporting Modules and Functions from Python `__init__.py`

    Any directory with `__init__.py` is considered a package in Python.

    Any python files inside a package is considered a module.

    Modules contain functions and other bindings that is always exported.

    If you are outside the package, and you want to import a module from a package:

    ```py
    from package import module
    module.use_function()
    ```

    However this is only because the `__init__.py` is empty. We can allow the
    package to export functions and modules as well. Which means this should be
    possible:

    ```py
    import package
    package.module.use_function()
    package.use_function()
    ```

    To do this, the package's `__init__.py` must contain something like:

    ```py
    from . import module
    from .mod import *
    ```

    Therefore the `__init__.py` is kind of like an exporting script for the package.
    Similar to how I use `index.js` in my JavaScript packages.