Добавление кода к __ init __. py
Как будто вы пытаетесь получить доступ к объекту, который является null. Рассмотрим ниже пример:
TypeA objA;
. В это время вы только что объявили этот объект, но не инициализировали или не инициализировали. И всякий раз, когда вы пытаетесь получить доступ к каким-либо свойствам или методам в нем, он будет генерировать NullPointerException, что имеет смысл.
См. Также этот пример:
String a = null;
System.out.println(a.toString()); // NullPointerException will be thrown
3 ответа
Весь импорт в __init__.py сделан доступным при импорте пакета (каталог), который содержит его.
Пример:
./dir/__init__.py:
import something
./test.py:
import dir
# can now use dir.something
РЕДАКТИРОВАНИЕ: забыл упоминать, код в __init__.py выполнения в первый раз, когда Вы импортируете любой модуль из того каталога. Таким образом, это обычно - хорошее место для помещения любого кода инициализации уровня пакета.
EDIT2: dgrant, на который указывают возможному беспорядку в моем примере. В __init__.py import something может импортировать любой модуль, не необходимый от пакета. Например, мы можем заменить его [1 110], затем на нашем верхнем уровне test.py оба из этих отрывков будет работать:
import dir
print dir.datetime.datetime.now()
и
import dir.some_module_in_dir
print dir.datetime.datetime.now()
нижняя строка: все имена присвоились в [1 112], быть, импортированные модули, функции или классы, автоматически доступны в пространстве имен пакета каждый раз, когда Вы импортируете пакет или модуль в пакете.
Это - просто персональное предпочтение действительно и имеет отношение к расположению Ваших модулей Python.
Скажем, у Вас есть модуль, названный erikutils. Существует два способа, которыми это может быть модуль, у или Вас есть файл, названный erikutils.py на Вашем sys.path, или у Вас есть каталог, названный erikutils на Вашем sys.path с пустым __init__.py файл в нем. Тогда скажем, у Вас есть набор модулей, названных fileutils, procutils, parseutils, и Вы хотите, чтобы те были подмодулями под [1 110]. Таким образом, Вы делаете некоторые .py файлы названными fileutils.py, procutils.py, и parseutils.py:
erikutils
__init__.py
fileutils.py
procutils.py
parseutils.py
, Возможно, у Вас есть несколько функций, которые просто не принадлежат fileutils, procutils, или parseutils модули. И скажем, Вы не испытываете желание создавать новый модуль, названный miscutils. И, требуется быть в состоянии вызвать функцию как так:
erikutils.foo()
erikutils.bar()
вместо того, чтобы делать
erikutils.miscutils.foo()
erikutils.miscutils.bar()
Поэтому, потому что erikutils модуль является каталогом, не файлом, мы должны определить, это - функции в __init__.py файл.
В django, лучший пример, о котором я могу думать, django.db.models.fields. ВСЕ django *Полевые классы определяются в __init__.py файл в каталог django/db/models/fields . Я предполагаю, что они сделали это, потому что они не хотели переполнять все в гипотетическое модель django/db/models/fields.py, таким образом, они разделяют ее на несколько подмодулей ( related.py, files.py, например), и они засунули сделанный *Определения поля в самом полевом модуле (следовательно, __init__.py ).
Используя __init__.py файл позволяет Вам делать внутреннюю структуру пакета невидимой из внешней стороны. Если внутренняя структура изменяется (например, потому что Вы разделяете один толстый модуль на два), только необходимо корректироваться __init__.py файл, но не код, который зависит от пакета. Можно также сделать части пакета невидимыми, например, если они не готовы к общему использованию.
Примечание, которое можно использовать эти del команда, таким образом, типичное __init__.py может быть похожим на это:
from somemodule import some_function1, some_function2, SomeObject
del somemodule
Теперь, если Вы решаете разделить somemodule, новое __init__.py могло бы быть:
from somemodule1 import some_function1, some_function2
from somemodule2 import SomeObject
del somemodule1
del somemodule2
С внешней стороны пакет все еще смотрит точно как прежде.