Czy __init__.py nie jest wymagany dla pakietów w Pythonie 3.3+

Używam Python 3.5.1. Przeczytałem tutaj dokument i pakiet: https://docs.python.org/3/tutorial/modules.html#packages

Teraz mam następującą strukturę:

/home/wujek/Playground/a/b/module.py

module.py:

class Foo:
    def __init__(self):
        print('initializing Foo')

Teraz, będąc w /home/wujek/Playground:

~/Playground $ python3
>>> import a.b.module
>>> a.b.module.Foo()
initializing Foo
<a.b.module.Foo object at 0x100a8f0b8>

Podobnie, teraz w domu, superfolder Playground:

~ $ PYTHONPATH=Playground python3
>>> import a.b.module
>>> a.b.module.Foo()
initializing Foo
<a.b.module.Foo object at 0x10a5fee10>

Właściwie mogę robić różne rzeczy:

~ $ PYTHONPATH=Playground python3
>>> import a
>>> import a.b
>>> import Playground.a.b

Dlaczego to działa? I choć nie musiał być __init__.pypliki (pustych będzie działać) w obu ai bdla module.pyaby być importable gdy pytona punkty ścieżka do Playgroundfolderu?

Wygląda na to, że zmieniło się to z Python 2.7:

~ $ PYTHONPATH=Playground python
>>> import a
ImportError: No module named a
>>> import a.b
ImportError: No module named a.b
>>> import a.b.module
ImportError: No module named a.b.module

Z __init__.pyobu ~/Playground/ai ~/Playground/a/bdziała dobrze.

Python 3.3+ ma niejawne pakiety przestrzeni nazw, które pozwalają mu tworzyć pakiety bez __init__.pypliku.

Zezwolenie na niejawne pakiety przestrzeni nazw oznacza, że ​​wymóg dostarczenia __init__.pypliku można całkowicie usunąć i wpłynąć na ...

Stary sposób z __init__.pyplikami nadal działa jak w Pythonie 2.

WAŻNY

@ Odpowiedź Mike'a jest poprawna, ale zbyt nieprecyzyjna. Prawdą jest, że Python 3.3+ obsługuje pakiety Implicit Namespace, które pozwalają mu tworzyć pakiet bez __init__.pypliku.

Dotyczy to TYLKO plików EMPTY__init__.py . Więc EMPTY__init__.py pliki nie są już potrzebne i można je pominąć. Jeśli chcesz uruchomić określony skrypt inicjujący podczas importowania pakietu lub dowolnego z jego modułów lub podpakietów, nadal potrzebujesz __init__.pypliku. Jest to świetna odpowiedź na pytanie o przepełnienie stosu, dlaczego chcesz użyć __init__.pypliku do przeprowadzenia dalszej inicjalizacji w przypadku, gdy zastanawiasz się, dlaczego jest to w ogóle przydatne.

Przykład struktury katalogów:

  parent_package/
     __init__.py            <- EMPTY, NOT NECESSARY in Python 3.3+
     child_package/
          __init__.py       <- STILL REQUIRED if you want to run an initialization script
          child1.py
          child2.py
          child3.py

parent_package/child_package/__init__.py:

print("from parent")

PRZYKŁADY

Poniższe przykłady pokazują, w jaki sposób skrypt inicjujący jest wykonywany podczas child_packageimportowania jednego lub jednego z jego modułów.

Przykład 1 :

from parent_package import child_package  # prints "from parent"

Przykład 2 :

from parent_package.child_package import child1  # prints "from parent"

Jeśli masz setup.pyswój projekt i korzystasz z find_packages()niego, konieczne jest posiadanie __init__.pypliku w każdym katalogu, aby pakiety mogły zostać automatycznie znalezione.

Pakiety są rozpoznawane tylko wtedy, gdy zawierają __init__.pyplik

UPD : Jeśli chcesz korzystać z niejawnych pakietów przestrzeni nazw, __init__.pymusisz po prostu użyć find_namespace_packages()zamiast tego

Dokumenty

Powiedziałbym, że należy pominąć __init__.pytylko wtedy, gdy ktoś chce mieć pakiet niejawnej przestrzeni nazw . Jeśli nie wiesz, co to znaczy, prawdopodobnie nie chcesz tego i dlatego powinieneś nadal używać __init__.pyparzystości w Pythonie 3.