Koniec wsparcia dla Pythona 2.7?

Czy jest znana data / ramy czasowe, kiedy Python 2.7 nie będzie już obsługiwany na korzyść Pythona 3?

Od 13 kwietnia 2014 r. Z http://hg.python.org/peps/rev/76d43e52d978 (harmonogram wydań PEP 373, Python 2.7):

Data końca życia (koniec okresu eksploatacji, data wygaśnięcia) dla Pythona 2.7 została przesunięta o pięć lat w przyszłość, do 2020 r. Ta decyzja została podjęta w celu wyjaśnienia statusu Pythona 2.7 i złagodzenia zmartwień tych użytkowników, którzy nie mogą jeszcze przejść na Python 3 Patrz także PEP 466 .

W maju 2010 roku Word of God ogłosił, że wydania poprawek dla Pythona 2.7 będą prawdopodobnie wydawane przez co najmniej 6 lat .

Więc może 2016 rok, prawdopodobnie później.

Edycja: przesunięto do 2020 r. Zobacz wersję PEP 373, do której link znajduje się w innych odpowiedziach.

Niedawno data ta została zaktualizowana do 1 stycznia 2020 r.

zobacz https://pythonclock.org/

powinieneś przeczytać to uważnie (ref: https://news.ycombinator.com/item?id=7582300 ):

Jest tu wiele komentarzy od ludzi, których nie ma na liście python-dev i tak naprawdę nie rozumieją, co właściwie oznacza ta różnica. Główni programiści nie są zobowiązani do utrzymywania 2,7 po 2015 roku, a większość z nich nie będzie w to zaangażowana. Ta część się nie zmieniła. Dzieje się tak, że Red Hat przygotowuje się do wycięcia wydania RHEL 7, które AFAIK w zależności od tego, ile zapłacisz im, oni obsługują przez 13 lat. Będą więc musieli wymyślić, jak samodzielnie wspierać 2.7 przynajmniej do 2027 roku. Tutaj czytam między wierszami. RH ma pełne prawo do rozwidlenia Pythona i zachowania poprawek konserwacyjnych dla siebie i swoich klientów (Python nie jest objęty licencją typu copyleft). Ale, są fajnymi facetami, więc może są skłonni do upstreamingu swoich zmian przynajmniej przez jakiś czas, jeśli nadal istnieje projekt Pythona, który chce je zaakceptować. Ponownie, to jest moja spekulacja oparta na dyskusji ML, a nie to, co RH powiedział, że zrobią. Można dokonać analogii do Rails LTS, komercyjnego rozwidlenia Rails 2.x, w którym patio11 było zaangażowane [0]. Nieuchronnie ktoś wkroczy w obsługę wersji 2.7, więc zobaczmy, co możemy zrobić, aby uniknąć sytuacji, w której jedynym sposobem na kontynuowanie działania 2.7 jest subskrybowanie RHEL. W międzyczasie jest kilka dużych firm, które intensywnie używają wersji 2.7 w systemie Windows (np. Enthought, Anaconda) i uważa się, że można znaleźć kogoś, kto stworzył instalator Windows od czasu do czasu, zakładając, że Python.org nadal będzie hostować pobieranie. Więc tak naprawdę to, co się tutaj dzieje, nie jest zbyt ekscytujące. Główni inicjatorzy nie robią nic innego niż opuszczenie projektu zgodnie z pierwotnym planem. To, co się dzieje, to pozostawienie włączonych świateł w repozytorium kontroli źródła i na serwerze FTP, aby uchwycić darmową siłę roboczą ludzi w dużych firmach, którzy są zainteresowani kontynuowaniem obsługi wersji 2.7. Alternatywą jest to, że RH i inni dostawcy tworzą zastrzeżone i drogie rozwidlenia Pythona 2.7. To może i tak się wydarzyć, ale Twój pracodawca zauważy, że powinieneś przestać dostarczać swoje poprawki, jeśli pliki binarne nadal pojawiają się na python.org i nie musisz prosić IT o skonfigurowanie SCM i narzędzia do śledzenia błędów, itp. To, co się dzieje, to pozostawienie włączonych świateł w repozytorium kontroli źródła i na serwerze FTP, aby uchwycić darmową siłę roboczą ludzi w dużych firmach, którzy są zainteresowani kontynuowaniem obsługi wersji 2.7. Alternatywą jest to, że RH i inni dostawcy tworzą zastrzeżone i drogie rozwidlenia Pythona 2.7. To może i tak się wydarzyć, ale Twój pracodawca zauważy, że powinieneś przestać dostarczać swoje poprawki, jeśli pliki binarne nadal pojawiają się na python.org i nie musisz prosić IT o skonfigurowanie SCM i narzędzia do śledzenia błędów, itp. To, co się dzieje, to pozostawienie włączonych świateł w repozytorium kontroli źródła i na serwerze FTP, aby uchwycić darmową siłę roboczą ludzi w dużych firmach, którzy są zainteresowani kontynuowaniem obsługi wersji 2.7. Alternatywą jest to, że RH i inni dostawcy tworzą zastrzeżone i drogie rozwidlenia Pythona 2.7. To może i tak się wydarzyć, ale Twój pracodawca zauważy, że powinieneś przestać dostarczać swoje poprawki, jeśli pliki binarne nadal pojawiają się na python.org i nie musisz prosić IT o skonfigurowanie SCM i narzędzia do śledzenia błędów, itp.

W tym artykule czytamy: „Po wydaniu wersji 2.7 linia 2.x przejdzie na pięć lat w trybie tylko do usuwania błędów”.

Tak więc, o ile widzę, Python 2.7 był ostatnim wydaniem dodającym funkcje 2.x. i chociaż znalezione błędy zostaną naprawione (przez jakiś czas), nowe funkcje będą dostępne tylko w wersjach 3.x.

Jest też dość złowieszczy zegar odliczający do EOS w 2020 roku.

PEP 373 (harmonogram wydań Pythona 2.7) jest oficjalnym źródłem informacji, o które prosiłeś.

Obecnie jest na nim napis „Planowane przyszłe daty wydania:”

• 2.7.7 maj 2014
• 2.7.8 listopad 2014
• 2.7.9 Maj 2015
• po tej dacie, w razie potrzeby wydania

Mówi też „Data końca życia (EOL, data wygaśnięcia) dla Pythona 2.7 została przesunięta o pięć lat w przyszłość, do 2020 r.”

Wydano w kwietniu 2014 r., Zgodnie z http://hg.python.org/peps/rev/76d43e52d978

Podręcznik programisty języka Python zawiera listę „ Status gałęzi języka Python ” od wersji 2.6 do wersji bieżącej, w tym ich aktualny stan wsparcia wraz z datami wycofania z eksploatacji.

Obecnie obsługiwane (błędy + poprawki bezpieczeństwa):

• Python 3.8 (aktualna gałąź główna / rozwojowa)
• Python 3.7.0
• Python 3.6.0
• Python 2.7 (do 2020-01-01)

Tylko poprawki bezpieczeństwa:

• Python 3.5
• Python 3.4.0

Python 2.7 będzie zawsze dostępny. Jest zbyt wiele starego kodu, który go używa, i nikt nie chce go przerabiać. Jest już widelec o nazwie Tauthon, ale możemy zobaczyć innych, jeśli ten bezcelowy termin się spełni.