Basso Livello anni 80

[keobox]

Una certa polarizzazione verso Ruby ci sta... se non è eccessiva.

Questa frase: "Il misterioso file init.py deve essere presente in una directory perché i file al suo interno vengano riconosciuti come moduli. Ogni altro linguaggio noto se la cava tranquillamente senza."

Non mi sembra esatta:

1. init.py definisce un package. I package rinforzano l'incapsulamento.
2. dire che "Ogni altro linguaggio noto se la cava tranquillamente senza" non mi sembra corretto. Per esempio Java definisce il package di appartenenza in ogni file .java di una certa directory

[gunzapper]

Non solo init.py rafforza l'idea che in python tutto è un oggetto, anche un modulo ha un init. Poi, l'init.py può essere usato per conservare informazioni come:

- quale codice esporre -> `__all__ = ['questo_file', 'questaltro_file']`
- definire una classe composta da due classi implementate in due diversi file dello stesso modulo
- trivia: autore, email, etc

[pmontrasio]

La polarizzazione è inevitabile data la mia storia pregressa. Ho chiesto il vostro intervento proprio per stemperarla. Spero di esserci riuscito almeno un po' mano a mano che attraverso le issue che avete aperto.

Ho fatto un po' di modifiche alla sezione su init.py 9611a0857cecf32c601cefdee4ef9b15660ac1e8 Possono andare?

[keobox]

Ok, grazie.

[rsalmaso]

In realtà dalla 3.3 (mi sembra) __init__.py non è più realmente indispensabile. Metti di avere un'app/libreria così fatta all'interno del:

mymodule/
mymodule/__init__.py
mymodule/utils.py

Se è presente __init__.py allora mymodule è un modulo (ha un attributo mymodule.__path__ e mymodule.__file__). Se non è presente è un namespace (non ha quegli attributi), e in realtà il contenuto può essere distribuito in più directory e python3 ne fa il merge.

[pmontrasio]

L'ho incluso con la commit [master cf43f01]