Dlaczego ludzie wahają się przed użyciem Python 3?

Python 3 został wydany w grudniu 2008 roku. Od tego czasu minęło dużo czasu, ale do dziś wielu programistów waha się przed użyciem Python 3. Nawet popularne frameworki, takie jak Django, nie są jeszcze kompatybilne z Python 3, ale nadal polegają na Python 2.

Jasne, Python 3 ma pewne niezgodności z Python 2 i niektórzy ludzie muszą polegać na kompatybilności wstecznej. Ale czy Python 3 nie istnieje już wystarczająco długo, aby większość projektów mogła się zmienić lub zacząć od Python 3?

Posiadanie dwóch konkurencyjnych wersji ma tak wiele wad; należy utrzymać dwie gałęzie, zamieszanie dla uczniów i tak dalej. Dlaczego więc tyle wahań w całej społeczności Python dotyczy przejścia na Python 3?

Pamiętaj, że nie aktualizuję już tej odpowiedzi. Mam dużo dłuższe pytania i odpowiedzi dotyczące Pythona 3 na mojej osobistej stronie http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_answers.html

Poprzednia odpowiedź:

(Aktualizacja statusu, wrzesień 2012 r.)

My (tj. Programiści Python) przewidzieliśmy, kiedy wydana została wersja Python 3.0, minie około 5 lat, zanim 3.x stanie się „domyślnym” wyborem dla nowych projektów z serii 2.x. Ta prognoza jest powodem, dla którego planowany okres konserwacji dla wydania 2.7 jest tak długi.

Oryginalna wersja Python 3.0 również okazała się mieć pewne krytyczne problemy ze słabą wydajnością IO, które sprawiły, że była ona praktycznie bezużyteczna dla większości praktycznych celów, więc sensowniejsze jest rozpoczęcie osi czasu od wydania Python 3.1 pod koniec czerwca 2009 roku. Problemy z wydajnością we / wy są również powodem, dla którego nie ma wydań konserwacyjnych 3.0.z: nie ma dobrego powodu, dla którego ktoś chciałby trzymać się wersji 3.0 zamiast aktualizacji do wersji 3.1).

W momencie pisania tego tekstu (wrzesień 2012 r.) Oznacza to, że obecnie trwamy nieco ponad 3 lata w procesie przejścia, a ta prognoza wciąż wydaje się być zgodna z planem.

Podczas gdy ludzie piszący kod Python 3 są najczęściej gryzie przez zmiany składniowe, takie jak stanie printsię funkcją, tak naprawdę nie jest to kłopotliwe z przenoszeniem bibliotek, ponieważ 2to3narzędzie do automatycznej konwersji radzi sobie z tym całkiem szczęśliwie.

Największym problemem w praktyce jest problem semantyczny: Python 3 nie pozwala na szybką i swobodną grę z kodowaniem tekstu, tak jak to robi Python 2. Jest to zarówno jego największa zaleta w stosunku do Pythona 2, ale także największa bariera przy przenoszeniu: musisz naprawić problemy z obsługą Unicode, aby port działał poprawnie (podczas gdy w wersji 2.x większość tego kodu cicho produkowała nieprawidłowe dane z dane wejściowe inne niż ASCII, co sprawia wrażenie pracy, szczególnie w środowiskach, w których dane spoza ASCII są rzadkie).

Nawet standardowa biblioteka w Pythonie 3.0 i 3.1 nadal ma problemy z obsługą Unicode, co utrudnia portowanie wielu bibliotek (szczególnie tych związanych z usługami internetowymi).

3.2 rozwiązało wiele z tych problemów, zapewniając znacznie lepszy cel dla bibliotek i frameworków takich jak Django. 3.2 przyniósł także pierwszą działającą wersję wsgiref(główny standard używany do komunikacji między serwerami WWW i aplikacjami WWW napisanymi w Pythonie) dla 3.x, która była niezbędnym warunkiem przyjęcia w przestrzeni internetowej.

Kluczowe zależności jak NumPy i scipy zostały przeniesione, narzędzia do instalacji i zarządzania zależność podoba zc.buildout, pipi virtualenvsą dostępne dla 3.x, uwolnienie Pyramid 1.3 obsługuje Python 3.2, nadchodząca Django 1.5 wydanie zawiera eksperymentalne wsparcie Python 3 i 12,0 uwolnienie szkielet sieci Twisted zrezygnował z obsługi Python 2.5, aby utorować drogę do utworzenia wersji zgodnej z Python 3.

Oprócz postępów w zakresie bibliotek i frameworków kompatybilności z Python 3, popularna implementacja interpretera PyPy skompilowana w JIT aktywnie działa na obsłudze Python 3.

Znacząco poprawiły się także narzędzia do zarządzania procesem migracji. Oprócz 2to3narzędzia dostarczanego jako część CPython (który jest teraz uważany za najlepiej przystosowany do jednorazowych konwersji aplikacji, które nie muszą utrzymywać wsparcia dla serii 2.x), istnieje również python-modernize, który wykorzystuje 2to3infrastrukturę do kierowania (duży) wspólny podzbiór Python 2 i Python 3. To narzędzie tworzy pojedynczą bazę kodu, która będzie działała zarówno w Python 2.6+, jak i Python 3.2+ za pomocą sixbiblioteki kompatybilności. Wydanie Python 3.3 eliminuje również jedną główną przyczynę „szumu” podczas migracji istniejących aplikacji obsługujących Unicode: Python 3.3 ponownie obsługuje przedrostek „u” dla literałów łańcuchowych (w rzeczywistości nie robi tegocokolwiek w Pythonie 3 - zostało właśnie przywrócone, aby uniknąć przypadkowego utrudnienia migracji do Pythona 3 dla użytkowników, którzy już poprawnie rozróżnili swój tekst i literały binarne w Pythonie 2).

Tak więc jesteśmy naprawdę zadowoleni z tego, jak postępują sprawy - wciąż upłynęły prawie 2 lata od naszego pierwotnego harmonogramu, a zmiany ładnie przebiegają w całym ekosystemie Python.

Ponieważ wiele projektów nie optymalizuje metadanych indeksu pakietów Python, a niektóre projekty z mniej aktywnymi opiekunami zostały rozwidlone w celu dodania obsługi języka Python 3, czysto zautomatyzowane skanery PyPI wciąż dają zbyt negatywny obraz stanu biblioteki Python 3 wsparcie.

Preferowaną alternatywą dla uzyskiwania informacji o poziomie obsługi Python 3 na PyPI jest http://py3ksupport.appspot.com/

Ta lista jest osobiście wyleczona przez Bretta Cannona (wieloletniego programistę w języku Python) w celu uwzględnienia niepoprawnych metadanych projektu, obsługi języka Python 3, który jest w narzędziach kontroli źródła, ale nie jest jeszcze w oficjalnej wersji, oraz projektów, które mają bardziej aktualne widelce lub alternatywy, które obsługują Python 3. W wielu przypadkach w bibliotekach, które nie są jeszcze dostępne w Python 3, brakuje kluczowych zależności i / lub brak obsługi Python 3 w innych projektach zmniejsza zapotrzebowanie użytkowników (np. gdy podstawowa platforma Django jest dostępna na Python 3, powiązane narzędzia, takie jak South i django-selery, częściej dodają obsługę Python 3, a dostępność obsługi Python 3 zarówno w Pyramid, jak i Django zwiększa prawdopodobieństwo, że obsługa Python 3 zostanie zaimplementowana w innych narzędziach, takich jak gevent).

Witryna pod adresem http://getpython3.com/ zawiera doskonałe linki do książek i innych zasobów dla Python 3, identyfikuje niektóre kluczowe biblioteki i frameworki, które już obsługują Python 3, a także zawiera informacje na temat tego, w jaki sposób programiści mogą uzyskać pomoc finansową od PSF w przenoszeniu kluczowych projektów do Python 3.

Innym dobrym zasobem jest strona wiki społeczności na temat czynników, które należy wziąć pod uwagę przy wyborze wersji Python dla nowego projektu: http://wiki.python.org/moin/Python2orPython3

Uważam, że wiele wątpliwości wynika z dwóch rzeczy:

• Jeśli nie jest zepsuty, nie naprawiaj go
• [Biblioteka XYZ], której wymagamy, nie ma portu 3.0

Istnieje kilka różnic w zachowaniu podstawowego języka, opisanych w tym dokumencie . Coś tak prostego, jak na przykład zmiana „print” z instrukcji na funkcję, spowoduje uszkodzenie dużej części kodu Python 2.x - i to tylko najprostsze. Całkowicie pozbyli się klas starszych w 3.0. W rzeczywistości są to całkiem różne języki - więc przenoszenie starego kodu nie jest tak proste, jak niektórzy mogą przypuszczać.

Istniejące firmy nie mają żadnych kompulsywnych powodów, by poświęcać czas, pieniądze i wysiłek na migrację do czegoś bez zmiany istniejącego zestawu funkcji. Mam na myśli, że baza kodu dla serii Python 2 działa od dawna, jest stabilna, przetestowana i ma wszystkie obecne funkcje produktu. Dlaczego ktoś miałby poświęcać czas, pieniądze i wysiłek, aby przenieść Python 3 tylko ze względu na migrację do niego.

Oprócz zapewnienia migracji po zakończeniu nie wystąpiły błędy regresji, a ból głowy jest nieunikniony.

W przypadku nowych projektów polityka jest prosta i zaczyna się od następujących punktów:

1. Czy jakieś dystrybucje, takie jak Ubuntu, dostarczają Python 3 podczas domyślnej instalacji?
2. Czym jest ekosystem biblioteczny dla Python 3.
3. Czy wszystkie frameworki i inne są kompatybilne z Python 3. itd. Itp.

Jest to zwykły proces „wybierania nowego języka”. Tutaj pojawia się problem z jajkiem kurzym. Niewiele osób go używa, ponieważ niewiele osób go używa. W końcu nikt nie ma ochoty się do tego ruszać.

Łamanie wstecznej kompatybilności nigdy nie było dobrą rzeczą, na końcu zawsze kończysz spory odsetek użytkowników.

Mniej więcej w momencie wydania Python 2.0 popularność Pythona szybko rosła. Było wielu nowych użytkowników, którzy naturalnie korzystali z najnowszej wersji, ponieważ nie mieli zależności od starszych wersji. Ponieważ wiele osób domyślnie przyjmuje 2.0, wywierano duży nacisk na twórców bibliotek itp.

Do czasu wydania Python 3.0 istniała już ogromna liczba użytkowników zależnych od Python 2.0, a wykładniczy wzrost (utrzymywanie stałego współczynnika w stosunku do istniejących użytkowników) oczywiście nie może być utrzymany w nieskończoność.

Osobiście nowe funkcje w Python 2 dni wydawały się o wiele bardziej atrakcyjne niż te oferowane przez Python 3.

Kiedyś myślałem, że Python 3 ostatecznie przejmie kontrolę, ale teraz nie jestem tego taki pewien. Ale nie tylko Python ma ten problem. W końcu ile osób uczciwie używa Perla 6? To trwa nieco dłużej niż Python 3, IIRC.

Dużym ogranicznikiem programu, dla którego nie wydaje mi się, że można je rozwiązać za pomocą automatycznego tłumaczenia, jest podział liczb całkowitych. Mam kody naukowe oparte na x / 2, dające x zaokrąglone w dół (gdy x jest liczbą całkowitą).

Python 3 nie zrobiłby tego, ale dałby odpowiedź .5 (dla nieparzystego x).
Nie mogę po prostu zamienić całego / w moim kodzie na //, ponieważ czasami robię dzielenie zmiennoprzecinkowe i dlatego chcę zachowanie zmiennoprzecinkowe.

Tak więc, aby przenieść się do Pythona 3, będę musiał przeszukiwać dziesiątki tysięcy wierszy kodu, sprawdzać każdy / i sprawdzać, czy mogę dowiedzieć się, czy powinien to być / lub //.

Python 3 miło jest rozpocząć nowy projekt, jeśli wszystkie potrzebne biblioteki są już przeniesione do Py3k.

Jeśli nie jest to opcja, używanie Python 2.7 jest najlepszym z obu światów: masz prawie każdą bibliotekę utworzoną dla Python 2.x i możesz stopniowo zmieniać swój kod, aby był kompatybilny z Py3k, dzięki czemu migracja jest łatwa, kiedy decydujesz to. Lista dodatków składniowych z Py3k, które już masz w wersji 2.7, jest raczej długa, po prostu nie zapomnij zaimportować __future__. Moimi ulubionymi są domyślnie Unicode, a podział zawsze tworzy zmiennoprzecinkowe.

Z perspektywy usług sieciowych: Żadna z głównych platform serwerowych ani struktur internetowych nie obsługuje Python3.

Aktualizacja: Oczywiście tak było na początku 2011 r., Obecnie (pod koniec 2013 r.) Większość głównych platform pracuje z Python3. Jednak niektóre nadal nie są kompatybilne. Istotnym przykładem może być Twisted, gdzie wciąż trwa .

Nie ma istotnych powodów, dla których widziałem używanie P3K, chyba że wykonujesz ciężką pracę na i18n. Podczas moich podróży odkryłem, że wszechobecny Unicode stanowi barierę dla mojej pracy (ASCII) i obowiązkowe generatory do blokowania mojego kodu.

Za kilka lat 3 będzie stanowić bardziej atrakcyjne środowisko, ale nie dzisiaj.

Dystrybucje nie udostępniają Python3. Istnieją pewne dystrybucje poboczne, które już przechodzą z Python2. Ale główne warianty Linuksa, takie jak Debian, Ubuntu itp. Nie. To jest główny powód, dla którego jako autor aplikacji też tego nie robię.

Chociaż przygotowałem przejście, a nawet starałem się unikać konstrukcji niekompatybilnych , nie mogę go poprawnie przetestować. To naprawdę sprowadza się do problemu kurczaka i jajka.