А ты перешел на Python 3?

PS слышу об отсутствии профитов только от тех кто на нём не прогает. Я думаю люди бессознательно ищут причину оставаться на старом питоне.

И какие же там профиты по сравнению со второй веткой?;-)

Моим заказчикам пофигу на чем я пишу;-)

всякого по мелочи. Типа Decimal быстрее работает.

Упал-пад-цтул. Ради этого надо было ломать обратную совместимость?;-)

Джанга будет поддерживать обе ветки с 1.5. Фласк хз когда потому что у его автора весь софт - набор ad-hoc костылей и хаков которые нереально портировать в разумные сроки.

Не умею писать на python. Пишу на python 3, все работает. К чему эти старпер-нюанс-рассуждения если версия 3 больше версии 2?

Согласен, не надо было - изменений слищком мало для этого. Кроме того, стандартные либы тоже поведение меняют.
Тем не менее подобных мелочей накопилось достаточно многои приятных изменений есть.

Пока все ныне живые продакшен дистрибутивы (rhel5,6, lucid) не переедут на тройку, либо не помрут, о переезде можно даже и не думать.

Есть проблемы с PIL, а в остальном все работает. Профита от перехода нет, кроме дальнейшей поддержки.

И какие же там профиты по сравнению со второй веткой?;-)

http://docs.python.org/3/whatsnew/3.3.html

http://docs.python.org/3/whatsnew/3.2.html

http://docs.python.org/3/whatsnew/3.1.html

http://docs.python.org/3/whatsnew/3.0.html

Я серьёзно. Можно говорить что «второй питон по-прежнему хорош», можно говорить что «и похапэ ничем не хуже», но это всё слова. Я уже говорил и скажу ещё раз что новая иерархия эксепшенов, убранная мешанина с str vs unicode, новые модули, старые модули с новыми возможностями итд итп делают код гораздо более аккуратным и причёсаным. Извращенцы будут радоваться yield from, извращенцы типа меня используют аннотацию для type checking, у subprocess есть check_output и DEVNULL для редиректа stdout и stderr(может бэкпортировали), теперь даже функцию def f(x): pass можно вызывать как f(x=1) (т.е. с keyword arguments), итд итп.

Короче, я бы сказал 65% преимуществ кроется в доработке стандартных либ, остальное в «общем дизайне» языка.

В общем, уже 4 года прошло с выхода 2.6, если кого-то всё устраивает то у того или фантазия бедная, или он другие ЯП не видел :).

Недостатки, правда, тоже есть. Местами стало неудобнее.

Это не бред, это баг http://www.logilab.org/ticket/110213

Вот так и тянет за язык сказать - I'm using Arch Linux. :)
Что-то накосячили в установке. :(

ну, в федоре и венде этот баг тоже есть.

Шапка с сусей еще долго не перейдут

Cоответственно python3 еще долго не будет в продакшене

Чорт, недосмотрел :)
Ну да ладно, будем думать, что этот баг из-за питона 3.3. (В арче 3.3?)
До дебиана еще не дополз, ставить и проверять не буду. Извини что втянул. :)

Я даже не знаю, что сказать... кроме как нового принта, который мне нравится большего старого, но который ломает обратную совместимость за что я его ЛЮТО ненавижу, в py3 нету ни одной новой фичи, к-я бы мне была нужна. Коллеги юзают str.format (в 2.7 оно есть), остальное... ну я правда активно пишу на питоне, причем с извращениями, выворачиваю наизнанку семантику а давеча и синтаксис растянул - но из новых наворотов меня ничего не греет.

Да, смена поведения целочсиленного деления - за одного это надо запретить кодить пожизненно и тому кто новый вариант придумал, и всем его родственникам до 7го колена! Это ж пппц...

менее кривой by design

два чая этому господину (самому лень было вспоминать примеры улучшений)

и таки да, никто лучше Changelog-а не скажет =)

что мне нравится (из того что не назвали выше) - стандартную библиотеку немного «причесали», убрали мешанину из больших и маленьких букв в именах классов... по типу TkInter, Queue, SocketServer... теперь всё маленькими буквами.

Питон очень корявый язык в том смысле что каждый может класть на PEP8 и писать как хочет... вот хоть немного причесали, и теперь модули именуют маленькими буквами.

проблема отнюдь не маловажная

Ещё... немаловажная фича (в первую очередь читайте список изменений 2.6 => 3.0, он явно посодержательнее, раз уж ломает обратную совместимость) - ленивость. Генераторы вместо списков.

Например те же zip, map и прочие функции работы со списками стали ленивыми. Думаю, профит от этого объяснять не надо?

стандартную библиотеку немного «причесали», убрали мешанину из больших и маленьких букв в именах классов... по типу TkInter, Queue, SocketServer

WAT. Имена классов как были CamelCase, так и остались.

Имена МОДУЛЕЙ. не классов

тьфу. править написанное до этого сообщение не могу. Оговорился. МОДУЛЕЙ, не КЛАССОВ.

Классы именуются верблюжьями буквами, ага

Нет, не надо. Лучше объясни, как поломается весь старый код, который считает, что эти функции возвращают старые добрые списки.

Это ж пппц...

ммм, ты про 3/4=0.75? Наоборот сделали как надо. Ещё одна причина перейти :).

выворачиваю наизнанку семантику а давеча и синтаксис

из новых наворотов меня ничего не греет.

да в этом плане у питона вообще никак :(. Я для себя решил больше не баловаться inspect и dis ибо чревато.

кроме как нового принта, который мне нравится большего старого

хм, а меня парит скобочки ставить... Особенно когда внутри print вызов других функций. Ну и захламляет... Вот такой я нежный.

как поломается весь старый код, который считает, что эти функции возвращают старые добрые списки.

2to3 оборачивает в list() чтобы ничего не поломалось.

проблема отнюдь не маловажная

ну, у каждого свои загоны :). Я хз откуда это у меня, но не люблю когда «неаккуратненько». К сожалению, жизнь меня жестоко карает в этом плане за перфекционизм - редко находишь satisfaction среди яп/либ/программ (хнык).

этот баг из-за питона 3.3

ммм, знаешь, как-то по характеру не похоже...

В арче 3.3?

Yeah,3.3, I'm using arch linux :)

как-то по характеру не похоже...

Да вот как раз в 3.3 они что-то с __import__ мутили. :)
А «Problem importing module... что-то там» как раз ексепшн от __import__.
Я не знаю, проверить то не могу, вот и предположил, так как в той баге у всех питон 3.3.

как раз ексепшн от __import__.

это у меня в папке был typecheck.py :))) Без него выдаёт только последнюю ошибку.

Хочешь сказать у всех 3 там отписавшихся в папке есть typecheck.py? :)
W0704 в модуле exceptions.py, как раз в том, что не может загрузить, но делают дизейбл этого варнинга без проверки что такой модуль загружен. (Кривенько, да)

хм, а меня парит скобочки ставить..

Вызов нормального билт ин метода, вместо убого дегенеративного подхака из simple statement'а. Если за это не убивать, то тогда за что?

Перешел, нравится.
Есть побайтовое чтение и запись из файлов, удобно же.
Напрягает только необходимость заключать в скобки аргументы print

ммм, ты про 3/4=0.75? Наоборот сделали как надо. Ещё одна причина перейти :).

Во первых, питон очень близок С-ям по всякой математической муйне. Кто в теме, тот ожидает, что 3/4=0. Я уж не говорю, про типизацию - делеим два инта, получаем флоат, зашибись!

Во вторых, при переводе со 2й на 3ю ветку еще можно там принтам скобочки поставить... но поймать в динамически типизированным ЯП целочисленное деление О_О... это ж скока багов при переводе появится!

Например те же zip, map и прочие функции работы со списками стали ленивыми. Думаю, профит от этого объяснять не надо?

Могу показать стандартный косяк:

$ python3.2
Python 3.2.3 (default, Jun 25 2012, 23:10:56) 
[GCC 4.7.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> L = map( float, '123')
>>> for i in L: print(i)
... 
1.0
2.0
3.0
>>> for i in L: print(i)
... 
>>>

Никаких профитов не вижу. Если мне нужен будет ленивый генератор - я заюзаю ленивый генератор. Не говоря о том, что ленивые генераторы экономят память, но сливают на небольших последовательностях обычным спискам по быстродействию вчистую. Коллега к-й юзал 3й питон жалился что то тормознутее, я вопрос не изучал, но из за ленивости такое вполне м.б.

менее кривой by design

Он не настолько стал прямее, что бы оправдать потерю обратной совместимости.

3.2 и 3.3 в целом почти как 2.7 у более ранних релизов были реальные проблемы со скоростью.

Он не настолько стал прямее, что бы оправдать потерю обратной совместимости.

Таки было решение самого Гвидо.

Когда я в своей библиотеке используемой от силы 10ю человеками хотел сломать обратную совместимость по сохраненным данным, меня 2 человека попросили этого не делать, и я к ним вынужден был прислушаться, они таки правы. Когда Гвидо, или разрабы гнуплота, ломают обратную совместимость (на ровном месте, в погоне за чистотой стиля) - они очень, очень неправы.

Привет.

Привет! :)

пробовали ли вы переводить свои проекты на 3-й пайтон и собираетесь ли вообще переходить на него?

Пишу для себя на 2-м удаве. На 3-й не перехожу и пока не собираюсь переходить. Не вижу смысла. Учи я сейчас заново язык - учил бы третий. А так, не хочется. Профитов не вижу, мало кто их вообще видит, просто гонятся за новым, как за поццерингом с системгэ.

Я заметил тормознутость при работе со строками. Правда в 3.1 было, ща может и починили.

Учи я сейчас заново язык - учил бы третий

А я бы раби. Или, вполне вероятно - перл.

именно что ломается... есть опыт.

например, старый код возвращает список

newlist = map(func, oldlist)

применения некоторой функции func к списку. И например после этого следует что-то вроде этого:

print newlist[0], newlist[1]

Утрирую, ну допустим их можно не печатать, но как-то по индексам обращаться... с итераторами такое не прокатывает.

да, увы.. я вообще не фанат этого языка, увы. именно из-за того, что он всё равно остался кривым :(

например меня убивают такие вещи

list = [1,2,3,4,5]

Экая Вы чуйствительная натура... тогда такие вещи как

a = 1

вместо убого дегенеративного подхака из simple statement'а.

вот за это и не люблю, нельзя делать свои стейтменты и операторы.

Кто в теме, тот ожидает, что 3/4=0

что это ещё за тема такая? наследие C? То что многие к этому привыкли не значит что это правильно. Наоборот это то обо что многие спотыкаются. Для меня более интуитивен результат float потому что в общем случае два int нацело не делятся если делитель не кратен делимому.

поймать в динамически типизированным ЯП целочисленное деление

а всего-то надо обернуть в int( ) результат. 2to3 можно научить, я думаю.

я думаю речь шла о переопределении list. Был тип bultins.list, стал инстансом со всеми вытекающими.

Я за это питон не люблю, много кратких имён уже занято.

поймать в динамически типизированным ЯП целочисленное деление

а всего-то надо обернуть в int( ) результат

Не, так просто не получится:

>>> -3/4
-1
>>> int(-3./4.)
0

ээх, ну тогда в math.floor

а всего-то надо обернуть в int( ) результат. 2to3 можно научить, я думаю.

Какие именно результаты? Я щас не говорю про то, что могут встречаться перегруженные операторы /, я про то, что где то оборачивать надо а где то нет. Вот есть простыня кода на 1000 строк со 100500 операторами деления. И?