3 ms·

init.py isn't exactly optional. The article sort of covers it, but if you don't include it, you are creating a namespace package, which is not the same as

__init__.py isn't exactly optional. The article sort of covers it, but if you don't include it, you are creating a namespace package, which is not the same as a regular package. As an example, see https://pypi.org/project/mir.msmtpq/ https://pypi.org/project/mir.msmtpq/ https://pypi.org/project/mir.sitemap/ https://pypi.org/project/mir.sitemap/ These use the `mir` namespace package to group separate packages. It's quite helpful as Python does not otherwise provide namespaces for the import namespace like Java or Go do. But likewise, you don't want to do that for regular packages as you're opening yourself up to getting clobbered by a similarly named package. It's somewhat comparable to PHONY in Makefiles. You could omit them. But you really shouldn't.

zahlman 2y ago
>But likewise, you don't want to do that for regular packages as you're opening yourself up to getting clobbered by a similarly named package. (I'm guessing the example is your own code? Also, I guess you meant "regular" in the ordinary English sense, but in the terminology of PEP 420, a "regular package" has `__init__.py` files by definition.) In principle, yes - you could get clobbered by such a package, in a different location on the system, that nevertheless uses the same name and also happens to be in `sys.path` for some reason. In principle, `__init__.py` files protect against this. But in practice, you would get clobbered anyway, because of how Pip works: $ cd Desktop $ python -m venv test_venv $ source test_venv/bin/activate (test_venv) $ pip install --only-binary=:all: mir.sitemap mir.msmtpq Collecting mir.sitemap Downloading mir.sitemap-1.1.0-py36-none-any.whl (3.2 kB) Collecting mir.msmtpq Downloading mir.msmtpq-1.0.0-py3-none-any.whl (10 kB) Installing collected packages: mir.msmtpq, mir.sitemap Successfully installed mir.msmtpq-1.0.0 mir.sitemap-1.1.0 (test_venv) $ ls test_venv/lib/python3.10/site-packages/ _distutils_hack pip distutils-precedence.pth pip-22.0.2.dist-info mir pkg_resources mir.msmtpq-1.0.0.dist-info setuptools mir.sitemap-1.1.0.dist-info setuptools-59.6.0.dist-info (test_venv) $ ls -R test_venv/lib/python3.10/site-packages/mir test_venv/lib/python3.10/site-packages/mir: msmtpq msmtpq.py __pycache__ sitemap test_venv/lib/python3.10/site-packages/mir/msmtpq: __init__.py __main__.py main.py __pycache__ queue.py sendmail.py test_venv/lib/python3.10/site-packages/mir/msmtpq/__pycache__: __init__.cpython-310.pyc main.cpython-310.pyc sendmail.cpython-310.pyc __main__.cpython-310.pyc queue.cpython-310.pyc test_venv/lib/python3.10/site-packages/mir/__pycache__: msmtpq.cpython-310.pyc test_venv/lib/python3.10/site-packages/mir/sitemap: __init__.py __pycache__ test_venv/lib/python3.10/site-packages/mir/sitemap/__pycache__: __init__.cpython-310.pyc Only one `mir` folder is created, and Pip blindly writes files from both wheels into that folder. Although namespace packages enable Python to split the package across separate folder hierarchies, that functionality isn't actually depended on. I can create and install my own conflicting wheel, and it will happily overwrite (by default! Without warning!) existing files, add `__init__.py` to the base `mir` folder, etc.

__init__.py isn't exactly optional. The article sort of covers it, but if you don't include it, you are creating a namespace package, which is not the same as

zahlman 2y ago

>But likewise, you don't want to do that for regular packages as you're opening yourself up to getting clobbered by a similarly named package. (I'm guessing the example is your own code? Also, I guess you meant "regular" in the ordinary English sense, but in the terminology of PEP 420, a "regular package" has `__init__.py` files by definition.) In principle, yes - you could get clobbered by such a package, in a different location on the system, that nevertheless uses the same name and also happens to be in `sys.path` for some reason. In principle, `__init__.py` files protect against this. But in practice, you would get clobbered anyway, because of how Pip works: $ cd Desktop $ python -m venv test_venv $ source test_venv/bin/activate (test_venv) $ pip install --only-binary=:all: mir.sitemap mir.msmtpq Collecting mir.sitemap Downloading mir.sitemap-1.1.0-py36-none-any.whl (3.2 kB) Collecting mir.msmtpq Downloading mir.msmtpq-1.0.0-py3-none-any.whl (10 kB) Installing collected packages: mir.msmtpq, mir.sitemap Successfully installed mir.msmtpq-1.0.0 mir.sitemap-1.1.0 (test_venv) $ ls test_venv/lib/python3.10/site-packages/ _distutils_hack pip distutils-precedence.pth pip-22.0.2.dist-info mir pkg_resources mir.msmtpq-1.0.0.dist-info setuptools mir.sitemap-1.1.0.dist-info setuptools-59.6.0.dist-info (test_venv) $ ls -R test_venv/lib/python3.10/site-packages/mir test_venv/lib/python3.10/site-packages/mir: msmtpq msmtpq.py __pycache__ sitemap test_venv/lib/python3.10/site-packages/mir/msmtpq: __init__.py __main__.py main.py __pycache__ queue.py sendmail.py test_venv/lib/python3.10/site-packages/mir/msmtpq/__pycache__: __init__.cpython-310.pyc main.cpython-310.pyc sendmail.cpython-310.pyc __main__.cpython-310.pyc queue.cpython-310.pyc test_venv/lib/python3.10/site-packages/mir/__pycache__: msmtpq.cpython-310.pyc test_venv/lib/python3.10/site-packages/mir/sitemap: __init__.py __pycache__ test_venv/lib/python3.10/site-packages/mir/sitemap/__pycache__: __init__.cpython-310.pyc Only one `mir` folder is created, and Pip blindly writes files from both wheels into that folder. Although namespace packages enable Python to split the package across separate folder hierarchies, that functionality isn't actually depended on. I can create and install my own conflicting wheel, and it will happily overwrite (by default! Without warning!) existing files, add `__init__.py` to the base `mir` folder, etc.