Clarify that packages don't need __init__.py - #1357

Love the change, thanks!

Love the change

I don't :D

It is not a big deal, probably can be considered nitpicking, and you can feel free to ignore this.

Honestly, I do not follow the logic of this change.

__init__.py is recommended to import the directory as a regular package

It is not just a recommendation, it is the only way to have the package be a regular package. If the file is not there then it is imported as a namespace package, isn't it? Python still considers it as a namespace package, doesn't it? Maybe there are no practical differences in most of the cases, but the sentence is still incorrect. Maybe the PEP says that the initializer can be omitted but it seems to me very much against the spirit of the PEP (what its author stated later on [1] [2]).

Is the intention of mentioning that __init__.py files can be omitted to make it easier for beginners?

If I recall correctly I have more than once helped fix people's projects by telling them to add missing __init__.py.

the general understanding in the community is that some tools might not fully support namespace packages yet (or be a bit more fussy about it) - although I cannot point out examples of these tools from the top of my mind...

Unless the behavior of those has changes since last time I checked (which was a long time ago, for sure):

• setuptools.find_packages()
• importlib.resources

Hi, @sinoroc the idea was a bit different: the recommendation is for people to add __init__.py so that packages are considered "regular packages". I agree that this is the only way a package is considered regular.

We can further clarify that if you prefer.

I don't know about importlib, but setuptools discovery supports namespace packages (the distinction is explicit via 2 separated API though). However, I do tend to recomend people nowadays to go for autodiscovery if the can, which will find namespaces without further configuration.