__init__.py: do we still need them?

[egpbos]

Since Python 3.3, empty __init__.py files are no longer necessary, because implicit namespace packages are the default; they require less configuration. We have an empty __init__.py in our template's tests directory that I think we can remove without any issue.

There is another __init__.py in the generated module directory (src/{package}/__init__.py). This one, however, contains some metadata. I was looking around for other places to put this information in the module, but in the end I started wondering: do we really need it in the module at all? Isn't having it in pyproject.toml enough for all practical purposes? If so, we can also delete that __init__.py as well. Thoughts?

[egpbos]

Btw (besides the point, but related): the __init__.py in the module is currently not strictly PEP8 compliant, the metadata tags should always come before any imports: https://peps.python.org/pep-0008/#module-level-dunder-names. If we don't remove it, we should fix it.

[sjvrijn]

+1 for deleting

[bouweandela]

From the documentation on packaging namespace packages:

Namespace packages allow you to split the sub-packages and modules within a single package across multiple, separate distribution packages (referred to as distributions in this document to avoid ambiguity). ... Namespace packages can be useful for a large collection of loosely-related packages (such as a large corpus of client libraries for multiple products from a single company). However, namespace packages come with several caveats and are not appropriate in all cases

The impression I get from reading this, is that they are needlessly complex for most use cases and should probably be avoided unless you have a good reason to use them. Having the __init__.py files around also gives you a good place to write documentation for your modules.

We probably don't need metadata tags in the __init__.py file, I've never seen that used in the wild.

[egpbos]

The impression I get from reading this, is that they are needlessly complex for most use cases and should probably be avoided unless you have a good reason to use them.

Do you mean namespace packages are complex? There's really not much complexity about them that I can see... Yes, they allow the more complex packaging option of splitting out optional parts of packages into separate packages, but in fact they do so in a way that makes it seem trivial. No configuration is necessary in most cases, everything is autodiscovered.

[bouweandela]

I mean

namespace packages come with several caveats and are not appropriate in all cases

Personally I do not have experience with using namespace packages, so I cannot tell what those caveats are, but one of those caveats that I am aware of is that standard tricks to figure out where a file is located (e.g. when you need some data that is located in the same directory as the Python module that is using it) module_name.__file__ or module_name.__path__ does not work in namespace packages and you need to use the more complicated importlib.resources standard library module. This can come as a surprise to unsuspecting users.

[BSchilperoort]

Do note that while __init__ is not required anymore for Python packaging, some tools still do depend on it.

I experienced that this week with the sphinx autoapi extension. It still doesn't fully/easily/properly support implicit namespace packages. For me the easiest fix here was to just add a __init__.py file in the right folder...

[egpbos]

Ok, Sphinx compatibility is important. I will retract my issue then, thanks for the discussion all.