Python 2 czy 3?

jezeli

1. python to Twoj pierwszy jezyk programowania

• nie ma znaczenia

1. zaczynasz uczyc sie pythona (kolejny jezyk programowania)

• nie ma znaczenia

1. potrzebujesz pythona uzyc z jakimis konkretnymi biblotekami

• zobacz czy sa dostepne (i czy dzialaja) pod wersja 3, jezeli tak mozesz uczyc sie 3 jezeli nie to ucz sie 2.7

i to by bylo na tyle.

Wersja 3 się bardziej opłaca jeśli chcesz kodować asynchronicznie, natomiast wersja 2 bardziej sprzyja rzeczom akademickim. Nie mniej lepiej jest znać obie wersje :)

Tak jak kolega napisał, jak dopiero zaczynasz abo to Twój kolejny język to nie ma znaczenia.

• nie ma znaczenia

Ma znaczenie takie, że Python 2 nie będzie rozwijany i choć pewnie długo jeszcze będzie na sztucznym podtrzymaniu, nie powinno się go używać w nowych projektach.

W podklejonym temacie masz nawet odpowiedź na to pytanie ;) Wybierz Pythona 2 tylko, jeśli
a) biblioteka, której nie da się zastąpić, nie wspiera Pythona 2
b) rozwijasz projekt w Pythonie 2, w którym zbyt czaso/pieniądzo-chłonne byłoby przepisanie go na Py3, albo nie da się z powodu wymienionego w poprzednim punkcie.
W przeciwnym razie Python 3.

Ucz się 3-ki, a jeżeli dany projekt, na którym przyjdzie Ci pracować będzie napisany w 2-ce, to zapoznaj się z subtelnymi różnicami między obiema wersjami. Nielogiczne jest uczenie się wersji, która nie będzie w przyszłości rozwijana. Owszem, z uwagi na kosmetyczne różnice między dwójką i trójką jako tako nie ma różnicy, której wersji zaczniesz się uczyć, bo niezależnie od wyboru będziesz umiał pisać w obu. Pytanie tylko po co w takim razie wybierać wersję przestarzałą, zamiast tej, która będzie rozwijana w przyszłości?

Na start, bym brał trójkie, bo już sporo modułów przepisano, a nie ma co się bawić w przestarzałym pythonie. 3.6 albo 3.7 ma wprowadzić możliwość programowania równoległego.

Różnice między v. 2.x a v. 3.x mają być kosmetyczne? To jak się zachowa aplikacja w której przez pomyłkę (a to się zawsze może zdarzyć) napisana pod v. 3.x i zastosowano gdzieś dzielenie na liczbach całkowitych z jednym tylko ukośnikiem zamiast dwóch?

W v. 2x jako wynik dzielenia 8/3 będzie 2 i będzie to liczba całkowita, zaś w v 3.x będzie floatem bo tu przez pomyłkę ktoś nie zastosował 8 // 3 ale 8 / 3 i lipa. Jakie to może mieć skutki, gdyby ktoś dla przykładu w pythonie napisał sobie na PC jakąś aplikację sterującą zachowaniem jakiegoś własnego quadro (np. przez Arduino i moduł nadawczo odbiorczy 433 MHz) a co dopiero amatorskiej rakiety?

Co to ma być? Zamiast porządnego komitetu który by ustalił pewne standardy i byłoby założenie o kompatybilności wstecznej, co moim zdaniem może być tu dość istotne o wszystkim decyduje twórca pythona który zdaje się jest dożywotnim dyktatorem? Jaką można mieć pewność że linia 4x będzie kompatybilna wstecznie z 3x bo o 2x to chyba już nie może być mowy? Teraz się uczycie pod 3x bo to jest rozwijane a wydaje mi się że py 2.7 jest nadal bardzo popularny a i jest od groma bibliotek pod tą wersję. Poza tym jest konwerter 2 to 3 więc nawet jak ktoś zna 2x to jaki to jest problem przekonwertować pod 3x? Są z tym jakieś istotne problemy? Bo po co niby jest ten konwerter?

@drorat1 nie przesadzaj. Rzecz w tym że takich różnic o których mówisz jest MAŁO. Dzielenie, print, kodowanie stringów to są takie 3 najpopularniejsze. Po co jest konwerter? Ano po to żebyś nie musiał lecieć ręcznie przez tysiące linii kodu i zamieniać print "dupa" na print("dupa") na przykład :)
Jak ktoś zaczyna przygodę z pythonem to nie pisze of razu softu do quadrocoptera, cubesata czy rakiety stratosferycznej. A jak już jest na tyle zaawansowany żeby taki soft pisać to nie zrobi takich błędów.

Konwersja czegoś takiego za pomocą 2to3:

a = 8 / 3
print(a)

nie spowoduje żadnych zmian:

RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
RefactoringTool: No files need to be modified.

A wynik działania w py 2.7: 2, w py 3.4: 2.6666666666666665

I gdzie tu mowa o przydatności tego narzędzia do konwersji?

Ale co to udowadnia? Nie jest to najfajniejsza sytuacja z 2 gałęziami języka, ale to i tak zawsze lepsza sytuacja niż wspieranie błędów ewolucji języka z racji kompatybilności wstecznej.

Ogólnie coraz więcej sensownych bibliotek jest przepisanych na 3. Nie warto na początek uczyć się starszej wersji. A jeśli ktoś chce komercyjnie używać Pythona i nie będzie znał różnic między dwiema odnogami, to cóż, nie wróżę mu kariery.

To dlaczego od razu nie przemyślano dość dobrze i z sensem kierunku rozwoju i nie przyjęto na sztywno pewnych konwencji tylko w 3x mamy zabawy tego typu i problem z kompatybilnością, to co podałem to tylko przykład że z tym pythonem należałoby niestety uważać. Przykładowo, duży projekt w DJANGO pod py 2.7, następuje później jakaś decyzja o aktualizacji pythona do 3x, co pociągnie dodatkowe koszta bo serwis np. przestaje działać poprawnie. Nie było by chyba takich problemów gdyby od początku zadbano o kompatybilność. Nie trzyma mi się kupy.

Ale to była decyzja przemyślana i po prostu uznano że ciągnięcie wstecznej kompatybilności w pewnych kwestiach sprawia że python3 byłby zwyczajnie gorszy niż by mógl. Języki sie rozwijają i nikt nie mógl przewidzieć kierunku rozwoju tego języka kiedy go tworzono (wiele lat temu...)

drorat1 napisał(a):

Nie było by chyba takich problemów gdyby od początku zadbano o kompatybilność. Nie trzyma mi się kupy.

Ja nie widzę problemu - chcesz pisać w języku zachowującym kompatybilność wsteczną, wybierz Javę. Tam masz gwarancję, że wszystkie błędy projektowe z pierwszej wersji będą także w najnowszej.