Python 3.2

Мил человек, это вопрос к мейнтейнерам вашего дистрибутива и к Вам, нафига Вам в системе 3 питона. У меня один например. Одно время 3 стояло - сам ставил на посмотреть, потом снёс.

isinstance придумали трусы?

>>> try:
...     f = open("aa", "r")
... except Exception as e:
...     str = unicode(e)
... 
Traceback (most recent call last):
  File "<input>", line 1, in <module>
UnicodeDecodeError: 'ascii' codec can't decode byte 0xd0 in position 10: ordinal not in range(128)

>> Она сделана в 2.0. Что в версиях после 2.4?

Это не поддержка, а говно.

Ну так ты объяснишь, что именно в поддерожке Unicode изменилось после 2.4, или как обычно?

Что за строка лежит в объекте A? unicode или str?

Напоминает анекдот: "- А если я тебя по голове монтировкой йопну, у тебя какой шнурок развяжется?" (с)

см выше

научись штоле ебилды читать

хотя, распарсить
python? ( || ( <dev-lang/python-3[xml] ( <dev-lang/python-3 dev-python/pyxml ) ) )
можно и так, в ебилдах особо не шаря.

Народ, а чего такой негатив на Пайсон? Надо быть выше этого.

Я, наоборот, с умилением читаю про «значительно переделан GIL», про «futures» и прочие «улучшен pdb» - пусть растет дитятко.

А пока поиспользую erlang.

Гг. Новый сборщик мусора, Unicode, newstyle-классы (метаклассы туда же), try-except-finally (через 15 лет после рождения языка %)).

Я про то что было в 2.3-2.5, дальше уже больше бэкпортов было чем оригинальных разработок(моё имхо на основе анализа чейнжлогов). Так вот сейчас изменений в 3.1 и 3.2 очень много сделали, активность очень большая. Да, забыл, во второй ветке аллокатор памяти сделали, это да, был прорыв.

>научись штоле ебилды читать
Да да, я уже понял, что стормозил

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

> Интересно, unladen swallow туда когда-нибудь запилят?

В 3.3 грозятся забабахать.

не выдерживают конкуренции серьезными платформами

выдерживает :).

> Я про то что было в 2.3-2.5

try-except-finally, with. Не прорывы, но удобно.

ну много писать, смотри сам:
Changes in Tcl/Tk
http://wiki.tcl.tk/405

минорные апдейты-фиксы?

Народ, а чего такой негатив на Пайсон? Надо быть выше этого.

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

Ога, по ссылке флеш и китайский язык.

In [1]: try:
   ...:     a = open('aa', 'rb')
   ...: except Exception as e:
   ...:     str = unicode(e)
   ...:     
   ...:     

In [2]: str
Out[2]: u"[Errno 2] \u041d\u0435\u0442 \u0442\u0430\u043a\u043e\u0433\u043e \u0444\u0430\u0439\u043b\u0430 \u0438\u043b\u0438 \u043a\u0430\u0442\u0430\u043b\u043e\u0433\u0430: 'aa'"

In [3]: print str
[Errno 2] Нет такого файла или каталога: 'aa'

ЧЯДНТ?

Скобочки ви таки готовы расставлять по указке?

а что вы до этого делали?

напишите короткий скрипт питона и увидите

В языке? И какие там боьшие изменения?

Для меня главное что они в итоге причесали язык до юзабельного состояния. Может действительно изменения не такие и большие, но код пишется легче и красивее и меньше вещей мозг парит(улучшили стандартную библиотеку, пофиксили GIL на SMP-системах, убрали тип long, улучшения в multiprocessing(бэкпортировали в 2.7), убрали oldstyle-классы, метод "".format(тормозной, скотина)).

Одни декораторы чего стоят.

о, чорт, я думал они всегда были :). Беру свои слова обратно.

Смотрел я ченжлог смотрел )

напишите короткий скрипт питона и увидите

проблемы с unicode и str в py3k с рождения нет, не вижу смысла обсуждать старую ветку питона в треде про новую ветку.

Еще раз посмотрел и ужаснулся: нам ставят в пример язык, где только в 2000-ых озадачилась нормально математической библиотекой\0

Народ не тупите уже были версии Python переписанные без GIL на одних семафорах и прочих - итог:
1. Очень трудно такой код поддерживать.
2. Оно на 30% медленнее для однонитевых приложений (как бы большинство приложений на данный момент)
3. Процентов на 20% быстрее в много нитевых приложениях.

Использование GIL крайне взвешенное решение и костылём его если и можно назвать то только для всей текущей концепции много тредового программирования на современных компьютерах.

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

При этом в Python есть возможность работать без GIL но тогда на тебя лягут все семафоры и локи. Так что выбор исключительно за программистом Python ни вчём не ограничивает.

Ничего. Написано же [1]

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

Так я как раз говорил про старую ветку, что проблема в ней, а в новой нет

>У мну jre1.5 и 1.6 стоят ибо в одном kvm(штука для управления серверами) работает а в другом нет.

И что? Написанное на 1.5 не работает в 1.6? Как-то сомнительно.

> Хотя, на самом деле, странно, почему там это сообщение сразу не в юникоде.

он в str пихает то, что выдает perror

ню ню, математическая либа была всегда (ТclX) , но в tcl 8.(хз минор ..) перекочевала в стандарт tcl .

исключительно python3 требуют java-config и lxml-2.x(а не libxml)

~$ pacman -Si python-lxml | grep Depends
Depends On     : python2  libxslt

А java-config, это, наверно, исключительно гентушный костыль, так что грызите сами.

Каким-то образом у меня defaultencoding — utf-8. Вот же беда.

Для меня главное что они в итоге причесали язык до юзабельного состояния....

Он и так достаточно юзабелен был. И остается, если немногие мигрируют на 3.Х. Максимум - это был сделан некий вектор на стандартизацию существующих подходов. Это все классно, мне нравится но совершенно не окупает порушенную обратную совместимость (например, поменялась работа со строками, а у меня ее мноооого в продакшене).

код пишется легче и красивее

Это не тот случай - выразительность у них примерно одинакова (как и у всех динамических ЯП на сегодня). Тот случай, например, с java на python.

о, чорт, я думал они всегда были :)

Это пример очень удачного сахара. Вполне можно было без них, но неудобно ни разу. За них, за функии, которые объекты первого класса и за сахар к коллекциям я многое питону прощаю.

И что? Написанное на 1.5 не работает в 1.6? Как-то сомнительно.

Сомнительно - не сомнительно, а не работает. Вот модель, если интересно: http://anlan.ru/catalog/5883

мои отступы генерятся кнопочкой i в vim-е, но опять же, по моей доброй воле, а не потому что конпелятор иначе не умеет.

Значит надо юзать locale.getpreferredlocale вторым аргументом unicode. Но вещь, конечно, печальная. Однако, больше похоже на местный баг, чем на проблему всей концепции.

Сгенери мне скобочки по доброй воле, терпеть их не могу :))

что вы пытаетесь доказать питоношкольникам, которые моложе tcl?

ну о том и речь, что в пистоне отступы возвели в ранг синтаксиса. это убого.

выразительность у них примерно одинакова

Ммм, не буду спорить, это всё субъективно. Для меня py3k другой язык с которым мне гораздо проще работать.

по моей доброй воле

Ну ты просто на принцип идёшь, реальной потребности в поддержке произвольных отступов у тебя нет.

> При этом в Python есть возможность работать без GIL

Как?

где я говорил, что они у меня производные?

если я на даче копаю кортошку в кирзачах, это не значит, что надо издать закон, по которому другая обувь на даче запрещена.

> что вы пытаетесь доказать питоношкольникам

А ты тот самый анонимус, который никак не может правильно написать слово «компилятор»? %)

произвольные*

> GIL - это костылик, который авторы Python сварганили на скорую руку, не осилив человеческий multithreading.

Не «не осилив», а «благоразумно избежав».

Из-за этого Python CANNOT INTO нормальное SMP.

Оно ему не надо. Высокопроизводительные числодробилки на питоне не пишут.

Для меня py3k другой язык

А для меня споры C vs Pascal всегда были довольно смешными, поскольку их отличия я не считал принципиальными

Тикл 8 был обратно совместим с тикл 7? Пруф?

Оу, а где это я писал такое ?

Чем оно лучше F#?

> Однако, больше похоже на местный баг, чем на проблему всей концепции.

Ага. А каким чудом я буду узнавать, что там на машине за локаль. Нет уж, все должно быть в unicode. Точнее строки вообще не должын от кодировки зависить