[{"data":1,"prerenderedAt":63},["ShallowReactive",2],{"qa-\u002Fpython\u002Fmodules\u002Fpackages":3},{"page":4,"siblings":53,"blog":44},{"id":5,"title":6,"body":7,"description":11,"difficulty":14,"extension":15,"framework":16,"frameworkSlug":17,"meta":18,"navigation":19,"order":12,"path":20,"questions":21,"related":44,"seo":45,"seoDescription":46,"stem":47,"subtopic":48,"topic":49,"topicSlug":50,"updated":51,"__hash__":52},"qa\u002Fpython\u002Fmodules\u002Fpackages.md","Packages",{"type":8,"value":9,"toc":10},"minimark",[],{"title":11,"searchDepth":12,"depth":12,"links":13},"",2,[],"medium","md","Python","python",{},true,"\u002Fpython\u002Fmodules\u002Fpackages",[22,27,31,35,40],{"id":23,"difficulty":24,"q":25,"a":26},"package-vs-module","easy","What is the difference between a module and a package, and what does __init__.py do?","A **module** is a single `.py` file. A **package** is a **directory** of modules\nthat you import as a unit, traditionally marked by an **`__init__.py`** file. That\nfile runs when the package is first imported, so it's where you can set the\npackage's public API or do setup; it's often empty, which is fine.\n\n```python\n# myapp\u002F                 \u003C- package\n#   __init__.py          \u003C- marks it a package, runs on import\n#   db.py                \u003C- module\n#   utils\u002F               \u003C- subpackage\n#       __init__.py\n#       text.py\n\nimport myapp.db                 # import a module from the package\nfrom myapp.utils.text import slug\n```\n\nA common use of `__init__.py` is to **re-export** so callers can write\n`from myapp import db` cleanly. Modules organize code into files; packages organize\nmodules into a namespace tree.\n",{"id":28,"difficulty":14,"q":29,"a":30},"python-m-main","What do `python -m` and __main__.py do?","**`python -m pkg.module`** runs a module **as a script** while still locating it via\nthe import system (so relative imports and the package context work). When you point\n`-m` at a **package**, Python runs that package's **`__main__.py`** — that's how a\npackage becomes executable, like `python -m http.server`.\n\n```bash\npython -m http.server 8000     # runs http.server's __main__.py\npython -m myapp                # runs myapp\u002F__main__.py\npython -m pytest               # run an installed tool as a module\n```\n\n```python\n# myapp\u002F__main__.py\nfrom myapp.cli import main\nmain()\n```\n\nUse `-m` to run installed\u002Fpackaged code by its import name rather than a file path,\nwhich avoids the `sys.path` surprises you get from running a file directly.\n",{"id":32,"difficulty":14,"q":33,"a":34},"dunder-all","What does __all__ control?","`__all__` is a list of names that defines a module's (or package's) **public API for\nwildcard imports** — `from module import *` imports exactly those names. Without it,\n`import *` grabs every name not starting with an underscore.\n\n```python\n# mymath.py\n__all__ = [\"add\", \"PI\"]      # only these are exported by *\n\ndef add(a, b): return a + b\ndef _helper(): ...           # private anyway\nPI = 3.14159\n\n# elsewhere\nfrom mymath import *         # gets add and PI only\n```\n\nIt does **not** prevent explicit imports (`from mymath import _helper` still works)\n— it only curates `*` and documents intent. Define `__all__` to keep `import *`\nclean and to signal what's officially public.\n",{"id":36,"difficulty":37,"q":38,"a":39},"namespace-packages","hard","What is a namespace package?","A **namespace package** (PEP 420) is a package with **no `__init__.py`** whose\ncontents can be **split across multiple directories** on `sys.path`. Python merges\nthose directories into one logical package — useful for plugins where different\ndistributions contribute to a shared top-level namespace.\n\n```python\n# path1\u002Facme\u002Ffoo.py\n# path2\u002Facme\u002Fbar.py     (no __init__.py in either acme\u002F)\n# with both paths on sys.path:\nimport acme.foo\nimport acme.bar          # both resolve under the merged 'acme' namespace\n```\n\nSince Python 3.3, a directory **without** `__init__.py` can still be importable as a\nnamespace package. For an ordinary single-location package you usually still want a\nregular package (with `__init__.py`); reserve namespace packages for splitting a\nnamespace across separately-installed parts.\n",{"id":41,"difficulty":14,"q":42,"a":43},"script-vs-import","What is the difference between running a file and importing it?","When you **run** a file (`python foo.py`), Python sets its `__name__` to\n**`\"__main__\"`**. When you **import** it, `__name__` is the **module's name**. The\n`if __name__ == \"__main__\":` guard uses this so a file can act as both a runnable\nscript and an importable library — the guarded code runs only on direct execution.\n\n```python\n# greet.py\ndef hello(name): return f\"Hi {name}\"\n\nif __name__ == \"__main__\":   # runs only via `python greet.py`\n    print(hello(\"world\"))    # NOT run when `import greet`\n```\n\nWithout the guard, your script's top-level side effects (running, printing, parsing\nargs) would fire **every time the module is imported**. Always put script entry\npoints behind the `__main__` guard.\n",null,{"description":11},"Python interview questions on packages vs modules, the role of __init__.py, python -m and __main__.py, __all__, namespace packages, and running a script versus importing it.","python\u002Fmodules\u002Fpackages","Packages & __main__","Modules, Packages & Environments","modules","2026-06-18","UrCSSzH8UD9IVaDM_gcmPtivyFD05XPsmRvHMSFzpps",[54,58,59],{"subtopic":55,"path":56,"order":57},"The Import System","\u002Fpython\u002Fmodules\u002Fimports",1,{"subtopic":48,"path":20,"order":12},{"subtopic":60,"path":61,"order":62},"Virtual Environments & pip","\u002Fpython\u002Fmodules\u002Fvirtual-environments",3,1781808681620]