Komentarze do: Python: wzajemne importowanie modułów http://room-303.com/blog/2009/07/22/python-wzajemne-importowanie-modulow/ Bug to the Feature Fri, 05 Mar 2010 09:43:10 +0000 http://wordpress.org/?v=2.9.2 hourly 1 Autor: japhy http://room-303.com/blog/2009/07/22/python-wzajemne-importowanie-modulow/comment-page-1/#comment-24484 japhy Wed, 22 Jul 2009 21:34:20 +0000 http://room-303.com/blog/?p=629#comment-24484 Zabawne, i "print foo.c" w bar.py rzuca AttributeError, a nie błąd w imporcie - czyli dostajemy częściowo załadowany moduł; cel pewnie jest taki, żeby móc się do całości modułu odwołać już w funkcji czy metodzie, wtedy nazwa rozwijana jest dopiero po załadowaniu całego foo - ale fajnie musi się coś takiego debugować ;) O Haystacku pisałem na podstawie jego dokumentacji, jeszcze go nie używałem; może bardziej zaawansowane wykorzystanie robi pętle - ale to IMO więcej kłopotu niż to warte (właśnie ze względu na zabawę z debugowaniem jeśli jednak coś pójdzie inaczej, niż myślimy - a kiedyś pójdzie). Zabawne, i „print foo.c” w bar.py rzuca AttributeError, a nie błąd w imporcie — czyli dostajemy częściowo załadowany moduł; cel pewnie jest taki, żeby móc się do całości modułu odwołać już w funkcji czy metodzie, wtedy nazwa rozwijana jest dopiero po załadowaniu całego foo — ale fajnie musi się coś takiego debugować ;)

O Haystacku pisałem na podstawie jego dokumentacji, jeszcze go nie używałem; może bardziej zaawansowane wykorzystanie robi pętle — ale to IMO więcej kłopotu niż to warte (właśnie ze względu na zabawę z debugowaniem jeśli jednak coś pójdzie inaczej, niż myślimy — a kiedyś pójdzie).

]]> Autor: Patrys http://room-303.com/blog/2009/07/22/python-wzajemne-importowanie-modulow/comment-page-1/#comment-24483 Patrys Wed, 22 Jul 2009 20:00:44 +0000 http://room-303.com/blog/?p=629#comment-24483 japhy: Oczywiście, że w jedną stronę możesz zażyczyć sobie <code>import foo</code> albo i <code>from foo import *</code>. Sprawdzenie tego nie zajmie ci więcej czasu niż napisanie komentarza. W cale nie pudło. Ostatnio problem w biurze był właśnie z aplikacją third-party (nazwy nie podam), która do spółki z Haystackiem tworzyła pętlę zależności (Haystack <em>wymusza</em> wczesne załadowanie <code>urls</code>, sprawdź w kodzie; obie aplikacje robiły swoje autodiscover metodą brute-force). japhy:

Oczywiście, że w jedną stronę możesz zażyczyć sobie import foo albo i from foo import *. Sprawdzenie tego nie zajmie ci więcej czasu niż napisanie komentarza.

W cale nie pudło. Ostatnio problem w biurze był właśnie z aplikacją third-party (nazwy nie podam), która do spółki z Haystackiem tworzyła pętlę zależności (Haystack wymusza wczesne załadowanie urls, sprawdź w kodzie; obie aplikacje robiły swoje autodiscover metodą brute-force).

]]> Autor: japhy http://room-303.com/blog/2009/07/22/python-wzajemne-importowanie-modulow/comment-page-1/#comment-24482 japhy Wed, 22 Jul 2009 18:57:15 +0000 http://room-303.com/blog/?p=629#comment-24482 Jest częściowe, bo kompletnego nie bardzo jest jak zaimplementować (nie zrobisz "from foo import *", a nawet "import foo" w bar.py, prawda?). A Haystacka albo importuję w models.py i sam wołam haystack.site.register() - albo: 1. w urls.py projektu importuję haystack 2. wołam haystack.autodiscover() 3. autodiscover importuje search_indexes.py w tych aplikacjach, w których jest dostępne 4. search_indexes.py może spokojnie zaimportować haystack - już został wcześniej zaimportowany przez urls.py, moduł jest już w pamięci. Discovery nie leci w czasie importowania haystacka - jest wykonywane później. Więc pudło. Jest częściowe, bo kompletnego nie bardzo jest jak zaimplementować (nie zrobisz „from foo import *”, a nawet „import foo” w bar.py, prawda?).

A Haystacka albo importuję w models.py i sam wołam haystack.site.register() — albo:
1. w urls.py projektu importuję haystack
2. wołam haystack.autodiscover()
3. autodiscover importuje search_indexes.py w tych aplikacjach, w których jest dostępne
4. search_indexes.py może spokojnie zaimportować haystack — już został wcześniej zaimportowany przez urls.py, moduł jest już w pamięci.
Discovery nie leci w czasie importowania haystacka — jest wykonywane później. Więc pudło.

]]> Autor: Patrys http://room-303.com/blog/2009/07/22/python-wzajemne-importowanie-modulow/comment-page-1/#comment-24481 Patrys Wed, 22 Jul 2009 15:12:09 +0000 http://room-303.com/blog/?p=629#comment-24481 japhy: Powinno być "a", literówka. Dlaczego "częściowe" wsparcie? Jest kompletne. Po co? Choćby Haystack - pierwsza z brzegu aplikacja Django, która importuje pozostałe aplikacje projektu, zbierając modele ORM do indeksowania. Z kolei twój kod chciałby pewnie móc coś w tym ideksie wyszukać, co wymaga zaimportowania Haystacka. japhy:

Powinno być „a”, literówka.

Dlaczego „częściowe” wsparcie? Jest kompletne. Po co? Choćby Haystack — pierwsza z brzegu aplikacja Django, która importuje pozostałe aplikacje projektu, zbierając modele ORM do indeksowania. Z kolei twój kod chciałby pewnie móc coś w tym ideksie wyszukać, co wymaga zaimportowania Haystacka.

]]> Autor: japhy http://room-303.com/blog/2009/07/22/python-wzajemne-importowanie-modulow/comment-page-1/#comment-24480 japhy Wed, 22 Jul 2009 15:00:48 +0000 http://room-303.com/blog/?p=629#comment-24480 Eee… a czy w trzeciej linijce bar.py nie powinno być przypadkiem "import c" albo "import a"? Nie do końca rozumiem, jak to miałoby działać - czy jeśli importowana z pętli zmienna jest zdefiniowana (przypisana) powyżej, a następnie zredefiniowana *poniżej* importu tworzącego pętlę - czy z pętli dostaniemy pierwszą wartość, czy błąd? Co jeśli zamiast redefinicji mamy zmianę mutowalnego stanu? Wydaje mi się, że częściowe wsparcie dla pętli importów to więcej zamętu niż korzyści. Bo i właściwie po co? Eee… a czy w trzeciej linijce bar.py nie powinno być przypadkiem „import c” albo „import a”? Nie do końca rozumiem, jak to miałoby działać — czy jeśli importowana z pętli zmienna jest zdefiniowana (przypisana) powyżej, a następnie zredefiniowana *poniżej* importu tworzącego pętlę — czy z pętli dostaniemy pierwszą wartość, czy błąd? Co jeśli zamiast redefinicji mamy zmianę mutowalnego stanu?

Wydaje mi się, że częściowe wsparcie dla pętli importów to więcej zamętu niż korzyści. Bo i właściwie po co?

]]> Autor: jarek http://room-303.com/blog/2009/07/22/python-wzajemne-importowanie-modulow/comment-page-1/#comment-24479 jarek Wed, 22 Jul 2009 14:43:25 +0000 http://room-303.com/blog/?p=629#comment-24479 Dla mnie zmorą są importy zaszyte np. w środku (pół biedy gdy są zaraz obok definicji) metody/funkcji. Czasami ciężko się połapać w takich potworkach jeśli są nieudokumentowane przez co wdrażanie/testowanie aplikacji jest o wiele bardziej upierdliwe nie mówiąc o pracy z takim kodem. Dla mnie zmorą są importy zaszyte np. w środku (pół biedy gdy są zaraz obok definicji) metody/funkcji.
Czasami ciężko się połapać w takich potworkach jeśli są nieudokumentowane przez co wdrażanie/testowanie aplikacji jest o wiele bardziej upierdliwe nie mówiąc o pracy z takim kodem.

]]>