Dlaczego stary plik .pyc łamał Django?

Wyciągnąłem najnowszy kod za pomocą git dzisiaj i mam następujący błąd:Dlaczego stary plik .pyc łamał Django?

ImportError at/
cannot import name Like

Może to mieć coś wspólnego z importu kołowych. Zbadałem traceback:

Traceback: 
File "/Library/Python/2.7/site-packages/Django-1.4.1-py2.7.egg/django/core/handlers/base.py" in get_response 
    101.        request.path_info) 
File "/Library/Python/2.7/site-packages/Django-1.4.1-py2.7.egg/django/core/urlresolvers.py" in resolve 
    298.    for pattern in self.url_patterns: 
File "/Library/Python/2.7/site-packages/Django-1.4.1-py2.7.egg/django/core/urlresolvers.py" in url_patterns 
    328.   patterns = getattr(self.urlconf_module, "urlpatterns", self.urlconf_module) 
File "/Library/Python/2.7/site-packages/Django-1.4.1-py2.7.egg/django/core/urlresolvers.py" in urlconf_module 
    323.    self._urlconf_module = import_module(self.urlconf_name) 
File "/Library/Python/2.7/site-packages/Django-1.4.1-py2.7.egg/django/utils/importlib.py" in import_module 
    35.  __import__(name) 
File "/Users/Desktop/python/mystuff/Project/Project/urls.py" in <module> 
    7. admin.autodiscover() 
File "/Library/Python/2.7/site-packages/Django-1.4.1-py2.7.egg/django/contrib/admin/__init__.py" in autodiscover 
    29.    import_module('%s.admin' % app) 
File "/Library/Python/2.7/site-packages/Django-1.4.1-py2.7.egg/django/utils/importlib.py" in import_module 
    35.  __import__(name)

Jedynym kod tam wyglądało, które mogą być przyczyną problemu był urls.py. Które miały następujący kod:

from django.contrib import admin 
admin.autodiscover()

Więc w tym czasie zauważam, że plik admin.py że wcześniej pisał został usunięty w najnowszej seryjnej ale że admin.pyc nadal istniał. Usunięcie pliku .pyc przebiegło w celu naprawienia błędu okrężnego importu, a teraz wydaje się, że wszystko działa dobrze.

Moje pytanie brzmi: co dokładnie się tutaj działo? Git jest skonfigurowany tak, aby ignorował wszystkie pliki pyc, więc po scaleniu plik .pyc utknął w miejscu pomimo usunięcia .py. Ale czy pyton nie powinien być na tyle sprytny, aby nie wywoływać żadnego skompilowanego kodu w pliku .pyc, jeśli sam .py został usunięty?

Źródło

2012-09-08 Chris

Nie wie, że został usunięty, a właściwie zawsze próbuje użyć 'pyc', jeśli nie ma' py' lub 'py' jest starsza. –

Dodaj to do swojego pliku 'root_directory/.gitignore':' * .pyc'. Poinformuje git, aby zignorował bajtów Pythona. Nie jest dobrym pomysłem, aby 'pyc' był częścią repozytorium, ponieważ każda lokalna funkcja mogłaby je edytować i mogłaby doprowadzić do błędów w środowisku wykonawczym, jeśli popchniesz je do innych, które nie mają twoich nowych modułów. –

nie, w rzeczywistości, Python użyć pliku .pyc korzystnie i tylko dostęp do pliku .py, jeśli: a) występuje b) jest nowszy niż plik .pyc.

Pozwala to na rozpowszechnianie aplikacji w Pythonie w postaci skompilowanej bez kodu źródłowego (choć nie jest to technika "zaciemniania" kodu).

Źródło

2012-09-08 22:19:32

Ta funkcja umożliwia także dystrybucjom systemu Linux instalowanie plików '.py' zainstalowanych pakietów w jednym miejscu i umieszczanie plików' .pyc' w każdym katalogu 'lib' w wersji Pythona (co jest prawdopodobnie bardziej użyteczną aplikacją). –

Rzecz można zrobić, aby temu zapobiec jest rozpoczęcie Django z

python -B manage.py runserver

lub zautomatyzować usuwanie PYC, prawdopodobnie z clean_pyc z django-rozszerzeń

./manage.py clean_pyc

Źródło

2012-09-08 22:26:58

Nie, Python (celowo, patrz poniżej) głupi na ten temat! Można uruchomić

find . -name '*.pyc' -delete

z katalogu projektu, aby pozbyć się starych .pyc plików.

Jeśli używasz git, możesz set up a hook zrobić to automatycznie przy kasie. Oto similar solution dla Mercurial.

Źródło

2012-09-08 22:28:18 ecmendenhall

Nie nazwałbym tego "głupim". Była to celowa decyzja projektowa, która ma wspierać ten proces i ma kilka przypadków użycia. To jest funkcja. –

Dlaczego stary plik .pyc łamał Django?

Odpowiedz

Powiązane problemy