Temat: Czy Django "zabije" serwer?

Piotr Rusoł:
Nie zrozumiałeś więc tłumaczę raz jeszcze. Różnica jest w kolekcjach. I nie ma tu mowy o deprecated. Jeśli będą potrzebować skorzystać z kolekcji 2.7, których nie ma w 2.6 bo na przykład dzięki nim mogą zrobić coś lepiej (krócej, szybciej) to pisząc ją w 2.6 i tak może się okazać że trzeba będzie ją przerobić pod 2.7. A jest kilka ciekawych kolekcji, które zostały dodane w 2.7 z gałęzi 3.x.

Zrozumiałem, zerknąłem na kolekcje już wcześniej. Mogą być rzeczywiście przydatne.
Mam wrażenie, że raczej Ty mnie nie zrozumiałeś. Powtarzam jeszcze raz, aby zastanowić się, czy zmiana interpretera na 2.7 bez korzystania z jego ficzerów ma sens. Instalacja dodatkowego interpretera, oprócz nakładu pracy na zestawianie całego środowiska niesie za sobą ryzyko, że w przypadku pomyłki popsuje się coś w bibliotekach dostarczanych z systemem. O ile w Windows nie ma takiego problemu, to w Linux wiele narzędzi systemowych (szczególnie w RHEL i pochodnych) napisanych jest w Python i rozwalając jakiś pakiet można sobie niepotrzebnych problemów narobić.
Instalacja kilku wersji Python w systemie jest jak najbardziej możliwa (sam to kiedyś przerabiałem), pytanie tylko, czy rzeczywiście jest w tym przypadku uzasadniona. Ale to wiedzą osoby tworzące aplikację, a nie my. I to one podejmą tą decyzję.

Robert jednak nic o nich nie wspominał. Zapytałem jednak wcześniej Roberta:

Robert Węglarek:

Mariusz Sucajtys:
Dlaczego tak się uparłeś na python 2.7? Co takiego w nim zmienili, że twoja aplikacja nie będzie działała na 2.6?

A czy to coś złego, że do pisania aplikacji wybraliśmy najnowszą wersję stabilną w 2.x, która bądź co bądź wisi już od pół roku?

Nigdzie nie padło, że chcą z kolekcji, szybszych obliczeń zmiennoprzecinkowych (o których jeszcze napiszę), ani innych ficzerów 2.7 korzystać.
Argument Roberta jest taki, że to jest wersja najnowsza, więc dlatego chcą się oprzeć na niej. Przypomina mi to trochę następującą scenę, czas 4:15-5:00
scenę, chodzi o drzwi :)

Piotr Rusoł:
Robert przyznał, że jednak będą w jakiś sposób obrabiać obraz/dźwięk więc i lepsza wydajność w obliczeniach zmiennoprzecinkowych z 2.7 może okazać się zbawienna.

Cytuję wypowiedź Roberta

Robert Węglarek:
Co do obrazów i dźwięków - obrazy sami przerabiamy, dźwięki mamy własną bibliotekę specjalnie pod aplikację napisaną używającą dodatkowo ffmpeg i sox + pakowanie po stronie serwera. Do tego mieszanie oryginału z dźwiękiem demo, miana częstotliwości itp więc obliczeń trochę się robi.
To tylko część funkcjonalności.

Nigdzie nie padło, w czym zaimplementowana jest biblioteka.
Jeżeli operacje realizują za pomocą biblioteki ffmpeg (napisanej w C), to prawdopodobnie większość obliczeń (szczególnie zmiennoprzecinkowych) realizowana jest przez kod napisany w C i tutaj wersja interpretera nie powinna mieć znaczenia, jeżeli chodzi o wydajność. Nie znamy jednak algorytmu, więc ciężko się wypowiadać, czy i jakie korzyści dałoby zastosowanie 2.7.
Jeżeli rzeczywiście dużo tych obliczeń wykonują, to i tak warto zastanowić się w dalszej perspektywie nad przepisaniem tych obliczeń w C i udostępnienie odpowiednich funkcji do Python.

Proponuję skończyć dyskusję, ponieważ odjechaliśmy od głównego wątku.
Więc powtarzając to, co już padło: Django nie zabije serwera. Jeżeli zestawi się to przy pomocy Apache/mod_wsgi albo nginx (FastCGI, Tornado, Gunicorn), to powinno działać nawet szybciej, niż php+XCache/APC. Unikaj zestawienia Apache/mod_python. Wątek serwera poruszałem zresztą już tutaj.Mariusz Sucajtys edytował(a) ten post dnia 05.06.11 o godzinie 18:13