2015-09-08 9 views
8

Niedawno miałem problem z pytaniem, gdzie signal I was using from flask-security was not behaving as expected w pythonie 3.3. Patrząc na kod źródłowy dla zabezpieczenia kolb zauważyłem, że sygnał, który importowałem z modułu w pakiecie zabezpieczeń kolb został również zaimportowany w __init__.py. Importując sygnał z najwyższego poziomu pakietu, udało mi się rozwiązać mój problem (ponieważ sygnał zostanie zaimportowany po zainicjowaniu pakietu).Różnica między pythonem 2.7 a 3.3+ podczas importowania w __init__.py i modułu z tego samego katalogu

Jeśli uruchomić następujący kod:

from flask.ext.security import user_registered 
from flask.ext.security.signals import user_registered as user_reg_sig 
user_registered==user_reg_sig 

Wezmę True w Pythonie 2.7 i dostanę False dla pytona 3.3+.

Co różni się w pythonie 3.3+, które powoduje tę różnicę w zachowaniu importu?

EDIT: nadal jestem zakłopotany przez pytona 2,7 vs emisji 3.3+, ale udało się zawęzić, że problem występuje, gdy __init__.py z flask.ext nazywa i wykorzystuje klasę ExtensionImporter z exthook.py do importowania zabezpieczenia kolbowego.

Prowadzenie następujących pod pytona 3,4 powraca True gdy kolba bezpieczeństwo bezpośrednio importowane unikając hak rozszerzenia:

from flask_security.signals import user_registered as user_reg_sig 
from flask_security import user_registered 
user_registered==user_reg_sig 

Oto reprezentujący() dla sygnałów o przykłady flask.ext.security i flask_security:

from flask_security.signals import user_registered as user_reg_sig 
from flask_security import user_registered 

repr(user_registered) 
>>> "<blinker.base.NamedSignal object at 0x7fb38e258400; 'user-registered'>" 

repr(user_reg_sig) 
>>> "<blinker.base.NamedSignal object at 0x7fb38e258400; 'user-registered'>" 

from flask.ext.security import user_registered 
from flask.ext.security.signals import user_registered as user_reg_sig 

repr(user_registered) 
>>> "<blinker.base.NamedSignal object at 0x7fb38e258400; 'user-registered'>" 

repr(user_reg_sig) 
>>> "<blinker.base.NamedSignal object at 0x7fb38dd030b8; 'user-registered'>" 
+0

A jeśli wydrukujesz repr każdego? –

+0

Dodano repr w pytaniu. Więc zdecydowanie inny obiekt, gdy dostęp za pośrednictwem flask.ext. – khammel

+0

Myślę, że ma to coś wspólnego z [http://stackoverflow.com/questions/4798589/what-could-cause-a-python-module-to-be-imported-twice] oraz zmianami w Python3.3 w ten obszar. Przeczytaj również [http://python-notes.curiousefficiency.org/en/latest/python_concepts/import_traps.html]. – mkiever

Odpowiedz

0

Istnieje wiele przypadków, w których Python może zdecydować o utworzeniu nowej instancji obiektu po ponownym imporcie modułu.

W rzeczywistości nie jest to nawet specyficzne dla Pythona 3 i może się zdarzyć w różnych sytuacjach.

Przede wszystkim należy założyć, że dwa obiekty mogą być różne i obejść to.

+0

Dzięki. Wygląda na to, że jest trochę problem z wykorzystaniem sygnałów przez Flask i co się dzieje, gdy import odbywa się przez flask.ext. * – khammel

Powiązane problemy