main.py:Python: dlaczego importowany moduł nie może odwoływać się do innego importowanego modułu?
import subone
import subtwo
subone.py:
a = 'abc'
subtwo.py:
print subone.a
Running python main.py
rzuca NameError: name 'subone' is not defined
. Spodziewałem się, że wydrukuje "abc".
Refaktoryzacja go używać from
import
i zajęcia nie pomaga:
main.py:
from subone import * # Only using from X import * for example purposes.
from subtwo import *
print 'from main.py:', a.out
subone.py:
class A:
out = 'def'
a = A()
subtwo. py:
# This throws NameError: name 'a' is not defined
print a.out
# This throws NameError: name 'A' is not defined
b = A()
print b.out
ale będzie print 'z main.py: def'. (Działa również przy użyciu import
).
Dlaczego to działa w ten sposób? Wygląda na to, że po zaimportowaniu subone
powinien on być dostępny pod numerem subtwo
.
Czy to dlatego, że złe programowanie polega na tym, że importowane moduły są od siebie zależne, bez przechodzenia przez ich "macierzysty" moduł? Czy istnieje inny, standardowy sposób, aby to zrobić?
Aktualizacja:
teraz rozumiem, że pierwszy przykład nie zadziała, ponieważ linia print subone.a
nie rozpoznaje nazwy subone
, nie będąc w subtwo
„s nazw (choć to w main.py
” s) i jest wywoływany z poziomu modułu subtwo
. Można to naprawić, używając import subone
na górze subtwo.py
- nie będzie on ponownie ładował modułu, ale doda go do przestrzeni nazw subtwo
, aby można było z niego korzystać subtwo
.
Ale co o tym:
main.py:
from subone import Nugget
from subtwo import Wrap
wrap = Wrap()
print wrap.nugget.gold
subone.py:
class Nugget:
gold = 'def'
subtwo.py:
class Wrap:
nugget = Nugget()
Myślę, że skoro Wrap
i Nugget
są zarówno ładowane bezpośrednio do main
„nazw s, które używają main
” nazw s oraz być w stanie odwołać się do siebie, ale to rzuca NameError: name 'Nugget' is not defined
. TO JEST, ponieważ Wrap
jest oceniane/sprawdzane od w przestrzeni nazwsubtwo
PRZED załadowaniem do przestrzeni nazw main
?
Twój enkapsulacji wydaje się naprawdę złamane ... – Daenyth
trzeba odnośnika leksykalny scopingu. Podstawową ideą jest to, że kod ma dostęp do tego, co "widzi" w kodzie źródłowym. to, co dzieje się w czasie wykonywania, nie ma z tym nic wspólnego. – aaronasterling