После 19 месяцев разработки представлен (http://www.python.org/getit/releases/3.3.0/) релиз языка программирования Python 3.3 (http://www.python.org). Python 3.3 является первой стабильной веткой, выпущенной после истечения моратория (https://www.opennet.ru/opennews/art.shtml?num=24234) на изменение синтаксиса языка, введённого вскоре после релиза Python 3.1 с целью предоставления возможности создателям альтернативных реализаций языка Python обеспечить в своих продуктах полную совместимость с классическим CPython 3.Среди добавленных в Python 3.3 новшеств (http://docs.python.org/py3k/whatsnew/3.3.html):
- Поддержка (http://www.python.org/dev/peps/pep-0405) виртуальных окружений, позволяющих использовать отдельные изолированные представления инсталляций Python, вынесенные в отдельные директории. Каждое виртуальное окружение содержит свой бинарный файл с интерпретатором Python (можно использовать разные версии Python) и свой набор пакетов. При этом все виртуальные окружения используют один общий набор стандартных библиотек Python. Для создания виртуальных окружений следует использовать модуль venv (http://docs.python.org/py3k/library/venv.html#module-venv);- Поддержка (http://www.python.org/dev/peps/pep-0380/) синтаксиса "yield from выражение" для делегирования части операций одного генератора другому генератору. Указанное нововведение позволяет вынести из генератора часть кода, содержащую 'yield', и поместить её к другому генератору. Значения, возвращаемые сформированными подобным способом субгенераторами, становятся доступны делегирующему генератору;
- Новые модули: "faulthandler" для диагностики крахов, "ipaddress" для манипулирования IP-адресами и "lzma" для сжатия данных методом LZMA/XZ;
- Переработанная (http://www.python.org/dev/peps/pep-3151) иерархия исключений для системных вызовов (os) и ввода/вывода (io);
- Улучшение поддержки Unicode. Адаптивное представление (http://www.python.org/dev/peps/pep-0393) Unicode-строк, позволяющее забыть о различиях между "wide" и "narrow". В объекты str добавлена поддержка универсального синтаксиса "u'" для явного указания unicode строк. Обеспечено более компактное хранение unicode-строк;- Переписанный на языке Си модуль "decimal" позволил до 80 раз увеличить производительность целочисленных операций;
- Использование по умолчанию importlib в качестве системы импорта (__import__);
- Поддержка (http://www.python.org/dev/peps/pep-0420/) отдельных пространств имён (Namespace) в пакетах, позволяющих разнести один Python пакет по нескольким директориям;
- Поддержка (http://www.python.org/dev/peps/pep-3155/) атрибута __qualname__ для явной идентификации родительских классов и функций;
- Возможность (http://www.python.org/dev/peps/pep-0409/) скрытия контекста исключений;
- Реализация (http://www.python.org/dev/peps/pep-0418) расширенных и независимых от платформы часов в модуле "time";
- Обеспечение (http://www.python.org/dev/peps/pep-0412) возможности совместного использования словарями идентичных ключей для хранения атрибутов объектов, что позволило существенно снизить потребление памяти для объектно-ориентированного кода;
- Добавлен класс "collections.ChainMap (http://docs.python.org/py3k/library/collections.html#collect...)" для связывания словарей в единое представление;
- В модулях "os" и "signal" добавлены обвязки для дополнительных POSIX-функций, таких как "sendfile()";
- По умолчанию включен режим рандомизации хэшей, нацеленный на решение проблемы с предсказуемыми коллизиями в реализации алгоритма хэширования для типов dict и set.URL: http://www.python.org/getit/releases/3.3.0/
Новость: https://www.opennet.ru/opennews/art.shtml?num=34971
>является первой стабильной веткой, выпущенной после истечения моратория на изменение синтаксиса языка,Хм, только я здесь вижу взаимоисключающие параграфы?
Ну так правильно с 3.1 по 3.3 синтаксис не меняли, а в 3.3 вон сколько изменений, сейчас начнётся новый цикл, мораторий на эти изменения, только баг-фиксы.
Нет, тут логическая ошибка
Нет, пожалуй всё правильно
да
У меня 2 вопроса:1. Таки как там с Unicode: лучше или хуже, чем в Java.
2. Как там с параллелизацией: потоки, актёры и т.п...Слышал я, что вообще в Питоне с этими вещами было паршиво. Может в этой версии уже нет?
Вам надо посмотреть Go.1. В Go всё Unicode -- полностью. Даже синтаксис. Серьезно! Вы можете называть переменные, названия функций и т.д. на кириллице. Создатели Go, Роб Пайк и Кен Томпсон -- авторы UTF-8.
2. Неотъемлемая часть языка. Посмотрите на goroutines.
> Вы можете называть переменные, названия функций и т.д. на кириллице.Зачем?
/me стонет
Как зачем? Думаю кодеры из 1С например будут только рады)))
> Как зачем? Думаю кодеры из 1С например будут только рады)))Подозреваю, что "кодеры из 1С" являются, в массе своей, однопрограммными или одноязычными, и никакие другие языки, кроме с трудом осиленного и изначально созданного для бухгалтеров диалекта 1С, их ничуть не интересуют. За примерами далеко ходить не нужно: подсистема обмена почтовыми сообзениями в 1С, FTP подсистема в 1С, ...
Какая уж тут радость - скорее огорчение.
> Подозреваю, что "кодеры из 1С" являются, в массе своей,однопрограммными или одноязычными
Вы ошибаетесь.
Что касается русскоязычных переменных, то это действительно на удивление очень удобно (для русскоязычных разработчиков). По сути текст программы - это просто текст на родном языке.
конструкцию
ЕстьПрава = Ложь;
...
Если ЕстьПрава Тогда
СделайТоТо();
КонецЕсли;
поймёт даже человек, который про язык 1с даже не слышал.
> прочитать сможет даже человек, который про язык 1с даже не слышал.Пофиксил.
Нормальный программист™ сразу же закроет окно с исходным кодом, а автора будет считать идиотом. А человек с улицы, не разбирающийся в программировании, 100% ничего не поймет, хоть и прочитать сможет.
Интересно, на каком языке пишет англоязычный "Нормальный программист"™ (ну, или, во всяком случае, именует переменные)? Может быть, на русском? Представляю себе фейспалм "Нормального программиста"™ Роба Пайка, там, или Ричи, когда они открывают исходник на C и видят, к примеру, следующий быдлокод:цел главный(цел аргк, сим **аргв) {
///...
вернуть ВЫХОД_УСПЕШНЫЙ;
}
В английском слова почти не склоняются/не спрягаются, так что программы на латинице выглядят не настолько бредово, как на кириллице. И еще английские слова короче при том же объеме информации - меньше писанины. Но к этому можно привыкнуть, это чисто субъективный недостаток на уровне "нравится - не нравится", как бы некоторым ни не хотелось этого признавать
Сразу видно человека, всю жизнь работающего в местечковой конторе и ничего кроме своего кода не видевшего.
Потому что хватает один раз увидеть код на несколько сотен метров, снабжённый комментариями на хрен знает скольки языках, дабы отучиться от подобных мыслей.
Фу как неполиткорректно! А как же мультикультурализм?
> Фу как неполиткорректно! А как же мультикультурализм?У вас политкорректность головного мозга.
«Цветным не нравится книга «Маленький чёрный Самбо». Сжечь её. Белым неприятна «Хижина дяди Тома». Сжечь и её тоже. Кто-то написал книгу о том, что курение предрасполагает к раку лёгких. Табачные фабриканты в панике. Сжечь эту книгу. Нужна безмятежность, Монтэг, спокойствие. Прочь всё, что рождает тревогу. В печку!! Похороны нагоняют уныние — это языческий обряд. Упразднить похороны.» — «451 градус по Фаренгейту», Рэй Брэдбери, 1953 год
Что общего у политкорректности и сжигания книг?
Сначала все начинается с политкорректности, а заканчивается сжиганием книг.
многие проявления политкорректности неполиткорректны
только чувства мусульман неприкосновенны, все неверные должны уважать аллаха. - так какой-то чурка в новостях говорил. я смеялся
Английский - профессиональный язык айтишников, как латынь - врачей. Смиритесь с этим. Ну или изобретите уже что-нибудь покруче Интернета.
Красота какая!Только право писать идентификаторы на родном языке автоматически обозначает возможность получения исходных текстов с идентификаторами на фиг знает каком языке.
Ад программиста скоро будет выглядеть так -
Имя функции и большинство идентификаторов - китайскими иероглифами, а потом смесь деванагари и кириллицы.Так что я лучше продолжу пользоваться ломанным английским...
Мне как-то довелось копаться в PHP-коде где всё было на итальянском (HotelDruid, есличо). Ничего, продрался, хотя в словарь нырять каждую минуту, конечно же напрягает.
Я это к тому, что возможность писать только латиницей сильно сужает число языков, но не сводит его к одному английскому. Надо ещё чтобы авторы понимали, что их код будет читать кто-то, говорящий на другом языке.
> возможность писать только латиницей сильно сужаетnikto, tem bolee, ne otmenyal translit
>> возможность писать только латиницей сильно сужает
> nikto, tem bolee, ne otmenyal translitза транслит в названиях надо убивать, предварительно медленно оторвав калёными щипцами тестикулы.
Появится профессия программист-переводчик.
а почему бы и нет ? :)
>> Вы можете называть переменные, названия функций и т.д. на кириллице.
>
>Зачем?
>/me стонетМне приходилось иметь дело со XSD схемой, написанной русскими буквами. JAXB быстренько преобразовал их в классы Java (в жабе можно использовать в именах UTF-символы, включая кириллицу), после чего я не стонал, а ругался: все время переключать раскладки очень неудобно. Только автозаполнение в NetBeans немного выручало.
>Зачем?Я тоже так думал, пока кто-то не привел мне пример. Правда, не с кириллицей, а с математическими формулами с греческими буквами. В научной программе, вполне вероятно, будет понятнее, если написать φ = ∏(p[i] ^ (α[i] - 1) * (p[i] - 1)), чем phi = product(pow(p[i], a[i] - 1) * (p[i] - 1)). Особенно если это код в середине научной статьи, где употребляются те же самые буквы.
кто мешает сделать транслятор из такой записи в то, что понимает компилятор и не тащить вредные фичи в сам компилятор?
>кто мешает сделать транслятор из такой записи в то, что понимает компилятор и не тащить вредные фичи в сам компилятор?Ну он уже есть, только встроен в компилятор, и не надо каждому писать свой велосипед.
В большинстве случаев не надо - большинство не пользуется. А кто очень хочет воспользоваться не к месту, тот и латинскими буквами напишет "void narisovatIzobrazhenie()".
Потом, популярные языки программирования (C++, Javascript, в какой-то мере Java) содержат колоссальное количество фич, позволяющих выстрелить себе в ногу (в C++ можно это сделать при сочинении Hello World). Почему бы не выкинуть "goto" из C и C++, если он нужен только очень редко?
> Ну он уже есть, только встроен в компилятор, и не надо каждому
> писать свой велосипед.зачем «каждому»? один написал и выложил.
> Почему бы не выкинуть «goto» из C и C++, если он нужен только очень редко?
потому что «выкинуть» — не то же самое, что «добавить». хотя из цпп гото выкинуть вполне нужно бы.
>> Ну он уже есть, только встроен в компилятор, и не надо каждому
>> писать свой велосипед.
> зачем «каждому»? один написал и выложил.
>> Почему бы не выкинуть «goto» из C и C++, если он нужен только очень редко?
> потому что «выкинуть» — не то же самое, что «добавить». хотя
> из цпп гото выкинуть вполне нужно бы.Конечно, лучше изобрести тысячу обёрток для указателей и запомнить особенности их поведения, которые ещё и меняются с каждым релизом библиотеки/языка.
C++ изначально мультипарадигменный, у него задача такая - давать возможность подстроиться. Иногда (и не так уж редко) goto удобен.
> Иногда (и не так уж редко) goto удобен.и когда же? в си — да, там нет finally. а зачем goto в c++? пользуйся механизмом исключений, он для того и запилен.
а, кстати: какие там у c++ «парадигмы»? обычный c, только сильно испорченый неудачной попыткой затащить туда ООП. удачная — это в ObjC.
>> Иногда (и не так уж редко) goto удобен.
> и когда же? в си — да, там нет finally. а зачем
> goto в c++? пользуйся механизмом исключений, он для того и запилен.Во-первых, исключения совсем для другого (хотя иногда области применения и могут перекрываться). Во-вторых, метки не порождают множества уровней вложенности - наоборот, они делают код "плоским". Иногда это плохо. Даже очень. А иногда - наоборот, упрощает и делает более удобочитаемым (sic!) код. Это не говоря о том, что добавление поддержки исключений утяжеляет программу чисто из-за добавления соответствующего кода компилятором, что для мелких утилит (Unix-way, всё такое) весьма заметно.
> а, кстати: какие там у c++ «парадигмы»? обычный c, только сильно испорченый
> неудачной попыткой затащить туда ООП. удачная — это в ObjC.C++ - это швейцарский нож. Со всеми недостатками и достоинствами швейцарского ножа. Он слишком тяжёл для многих простых задач. Но там, где нужно совмещать высоко- и низкоуровневые сущности, ему нет равных. И коли уж мы их совмещаем, то глупо не пользоваться имеющимся инструментарием. Попытки использовать C++, скажем, чисто для ООП, с избеганием даже тени процедурного подхода, выглядят грустно.
Objective C - приятный язык. Просто другой.
> Во-первых, исключения совсем для другого (хотя иногда области применения и могут перекрываться).вот с этого места поподробней. а то начинает закрадываться подозрение, в котором фигуриует слово «говнокод».
> Во-вторых, метки не порождают множества уровней вложенности — наоборот, они делают
> код «плоским».долой циклы! и вообще блоки. только метки, только плоский код! (пардон, не удержался)
goto в c++ всё равно приходится увязывать с объявлениями более-менее сложных объектов. в итоге получается каша. которую чаще проще и красивей можно решить при помощи декомпозиции, грамотного применения return и да — исключений.
> что добавление поддержки исключений утяжеляет программу чисто из-за добавления соответствующего
> кода компилятором, что для мелких утилит (Unix-way, всё такое) весьма заметно.зачем писать мелкие утилиты на цпп? если используются фичи библиотек цпп, то утилита и так распухнет. а если нет — то чего было выпендриваться?
> C++ — это швейцарский нож.скорее голландский сыр.
> Попытки использовать C++, скажем, чисто для ООП, с избеганием даже тени процедурного подхода, выглядят грустно.
потому что нормального ООП там нет. дурацкий симула-подход, который растиражировали остальные — костыль-пародия.
> Objective C — приятный язык. Просто другой.
ага. наглядно показывающий, что такое ООП и как надо его добавлять, оставаясь полностью совместимым с C. я, правда, на ObjC2 не смотрел: кажется, начали портить.
>> Во-первых, исключения совсем для другого (хотя иногда области применения и могут перекрываться).
> вот с этого места поподробней. а то начинает закрадываться подозрение, в котором
> фигуриует слово «говнокод».Что именно "поподробней"? Страуструпа пересказывать как-то не хочется. Исключения, если уж сравнивать с переходами по меткам, то тем, которые setjmp()/longjmp() и иже с ними. Их задача - не добавляя множества явных путей, передать управление в случае нестандартной ситуации в нужное место через произвольное количество уровней на стеке. При использовании "умных" указателей и finally { ... } их можно использовать для подчистки, да. Но, во-первых, вы когда-нибудь видели в не очень-то и сложном методе пять уровней вложенности finally? Это адЪ, особенно при наличии вложенных циклов и всяких там if'ов в промежутке. А во-вторых, goto бывает полезен в неочевидных ситуациях. Верить заставлять не собираюсь. Если будет конкретное доказательство абсолютной бесполезности (даже не вреда) goto в C++ - можно будет говорить предметно.
>> Во-вторых, метки не порождают множества уровней вложенности — наоборот, они делают
>> код «плоским».
> долой циклы! и вообще блоки. только метки, только плоский код! (пардон, не
> удержался):-P Пардон пардоном, а из контекста вырывать нехорошо.
> goto в c++ всё равно приходится увязывать с объявлениями более-менее сложных объектов.
> в итоге получается каша. которую чаще проще и красивей можно решить
> при помощи декомпозиции, грамотного применения return и да — исключений.Такая каша возникает обычно из-за смешивания уровней логики. Частая проблема - неумение, а порой и практическая невозможность, произвести декомпозицию функции/метода приводит к гипертрофированию оного. В этом случае goto действительно становятся бОльшим злом, нежели умные обёртки и многоступенчатые try { ... }.
>> что добавление поддержки исключений утяжеляет программу чисто из-за добавления соответствующего
>> кода компилятором, что для мелких утилит (Unix-way, всё такое) весьма заметно.
> зачем писать мелкие утилиты на цпп? если используются фичи библиотек цпп, то
> утилита и так распухнет. а если нет — то чего было
> выпендриваться?Утяжеление не только за счёт размера кода, но ещё и за счёт дополнительно работающего кода (снижение производительности, все дела). Хотя заранее соглашусь, потери сравнительно небольшие, если не запускать процессы тысячу раз в секунду. :)
>> C++ — это швейцарский нож.
> скорее голландский сыр... а кому и свиной хрящик. Дело вкуса.
>> Попытки использовать C++, скажем, чисто для ООП, с избеганием даже тени процедурного подхода, выглядят грустно.
> потому что нормального ООП там нет. дурацкий симула-подход, который растиражировали остальные
> — костыль-пародия.Ну нет. И что? Программы на C++ почему-то продолжают исправно работать несмотря на свою не-ООПность. Хуже того - такой языковой кошмар для любителей элегантности, как Perl, тоже продолжает существовать вместе с тоннами написанного на нём кода - и далеко не всегда такого уж плохого.
Я готов согласиться с тем, что C++ - это мегакостыль. Возможно, самый большой костыль за всю историю программирования. Но пока ничего глобально лучшего нет - только нишевые решения. Так что увы.
> Что именно «поподробней»?зачем нужны goto, окромя как:
а) эмулировать finally, и
б) выбираться из очень глубоких циклов (что в большинстве случаев, пардон, означает говнокод, который надо переписать нормально — возможно, изменив логику).> вы когда-нибудь видели в не очень-то и сложном методе пять уровней вложенности
> finally?но зачем? это или человек не знает про автоматические объекты, или у него руки не в ту точку примонтированы.
> А во-вторых, goto бывает полезен в неочевидных ситуациях.
вот про это я и просил «поподробней».
> Верить заставлять не собираюсь. Если будет конкретное доказательство абсолютной бесполезности
> (даже не вреда) goto в C++ — можно будет говорить предметно.вообще-то намного проще доказать нужность — для этого достаточно одного примера, который без goto или не делается никак, или делается настолько криво, что «ужас-ужас-ужас», и переписать нормально который не выходит.
а для доказательства «ненужности» надо рассмотреть *все возможные применения* goto. это нереально.
> :-P Пардон пардоном, а из контекста вырывать нехорошо.
ну я же говорю: не удержался. %-)
> Утяжеление не только за счёт размера кода, но ещё и за счёт
> дополнительно работающего кода (снижение производительности, все дела).если в программе возникла исключительная ситуация — то это, пардон, исключительная ситуация. если программа *вся* построена на кидании исключений — это уже клиника. а при нормальном execution flow накладные потери на поддержку механизма исключений настолько малы, что можно не обращать на них внимания. ибо если таки надо обращать, то язык явно был выбран неправильно.
> Ну нет. И что? Программы на C++ почему-то продолжают исправно работать несмотря
> на свою не-ООПность.а это вообще к теме беседы не относится.
> Но пока ничего глобально лучшего нет — только нишевые решения.
пардон, даже D лучше. не надо путать «есть куча людей, которые кое-как умеют писать на C++, да куча кода написана — потому это лучшее решение» с «архитектурно ничего лучшего не придумали». «куча кода и людей» не обозначает «хорошо» — достаточно взглянуть на PHP.
Да и потом, смотри, как можно увеличить наглядность названий во многих программах:Microsoft®InternetExplorer®DownloadURL := "http://windows.microsoft.com/ru-RU/internet-explorer/product...
>>кто мешает сделать транслятор из такой записи в то, что понимает компилятор и не тащить вредные фичи в сам компилятор?
> Ну он уже есть, только встроен в компилятор, и не надо каждому
> писать свой велосипед.
> В большинстве случаев не надо - большинство не пользуется. А кто очень
> хочет воспользоваться не к месту, тот и латинскими буквами напишет "void
> narisovatIzobrazhenie()".
> Потом, популярные языки программирования (C++, Javascript, в какой-то мере Java) содержат
> колоссальное количество фич, позволяющих выстрелить себе в ногу (в C++ можно
> это сделать при сочинении Hello World). Почему бы не выкинуть "goto"
> из C и C++, если он нужен только очень редко?Ой ну вот ненадо, на си пару раз себе в ногу стрельнешь и все. Научился обращаться.
Да сложно, да нужно башко думать.
> Вам надо посмотреть Go.а напаркуа? В Go есть тысячи хороших библиотек? Может быть хотя бы 10 фреймворков? Голый язык с понтами и кучкой приближенных сектантов. До Python еще пилить и пилить, а до JM, как до Солнца улиткой.
> Слышал я, что вообще в Питоне с этими вещами было паршиво.Рабинович напел?
> У меня 2 вопроса:
> 1. Таки как там с Unicode: лучше или хуже, чем в Java.
> 2. Как там с параллелизацией: потоки, актёры и т.п...
> Слышал я, что вообще в Питоне с этими вещами было паршиво. Может
> в этой версии уже нет?В Tcl с unicode все отлично, например. Потоки, мьютексы, пулы потоков, до версии 8.5 расширением, в 8.6 есть поддержка кооперативной многопоточности в ядре языка.
Зато в Tcl с синтаксисом очень паршиво.
> Зато в Tcl с синтаксисом очень паршиво.На Паскаль не похож?
Забавные у вас представления о паршивости синтаксиса.
Нет, в случае с Tcl проблемы гораздо глубже.
> Забавные у вас представления о паршивости синтаксиса.
> Нет, в случае с Tcl проблемы гораздо глубже.Хотел бы немного подискутировать на тему проблем, если Вы не против.
> Хотел бы немного подискутировать на тему проблем, если Вы не против.ОноНеПохожеНаСи!!111111
Мне однажды пришлось писать на tcl, правда, совсем немного - нужен был скрипт на Expect, способный делать более сложные штуки, чем "дождаться login, послать логин, дождаться password, послать пароль", на всё ушло около часа, при том, что раньше с tcl не соприкасался. Никаких таких ужасных особенностей в синтаксисе tcl я тогда не усмотрел.
Tcl поддерживает Unicode ограниченно — только Basic Multilingual Plane.
> Tcl поддерживает Unicode ограниченно — только Basic Multilingual Plane.а больше ничего и не нужно. китайцев-корейцев-японцев-и-прочих-красавцев надо вообще выпилить нафиг из юникода.
Зачем вам уникод? ASCII хватит для всех.
> Зачем вам уникод? ASCII хватит для всех.зачем в юникоде эти дурацкие иероглифы, отдельные диакритические знаки и композиты? мусор это всё. кто не хочет вводить нормальный алфавит — должен страдать.
Правильно. Зачем в кириллице буквы, дублирующие латинские, — А, В, Е, К, М, Н, О, Р, С, Т, У, Х? Зачем Г, если есть G? Зачем переворачивать нормальные буквы — И, Я, Ь?
не тупи.
> 2. Как там с параллелизацией: потоки, актёры и т.п...А где сейчас с параллелизацией хорошо? Неужели в джаве? А я всегда думал что джава и параллельные вычисления это взаимно исключающие параграфы. Что-то получше должно быть в ерланге и хаскелле, но опять же программировать на них почти невозможно. Резолюция проста и неутешительна: параллельные вычисления это миф
> А где сейчас с параллелизацией хорошо? Неужели в джаве? А я всегда
> думал что джава и параллельные вычисления это взаимно исключающие параграфы. Что-то
> получше должно быть в ерланге и хаскелле, но опять же программировать
> на них почти невозможно. Резолюция проста и неутешительна: параллельные вычисления это
> мифА в это время суровые сишники продолжали писать распараллеленные числодробильные приложения.
Господа! Смертельный номер господа!Обычному домашнему хомячку подсунули каплю никотина:
>Что-то получше должно быть в ерланге и хаскелле,Охщи ...
>но опять же программировать на них почти невозможно. Резолюция проста и неутешительна: параллельные вычисления это мифГоспода - приносим извинения за ошмётки несчастного смелого хомячка долетевшие да первых рядов ...
> в ерланге и хаскелле, но опять же программировать на них почти невозможночто, не похоже на похапэ? бывает.
>У меня 2 вопроса:
>1. Таки как там с Unicode: лучше или хуже, чем в Java.В 3 ветке лучше, во 2-ой хуже.
>2. Как там с параллелизацией: потоки, актёры и т.п...
Все хорошо.
>Слышал я, что вообще в Питоне с этими вещами было паршиво. Может в этой версии уже нет?
Вы не понимаете http://xkcd.ru/353/
На самом деле с параллелизацией там всё ужасно из за GIL, который банально не дает нескольким тредам одновременно исполняться.
http://habrahabr.ru/post/84629/То есть для многопоточного программирования Питон по просту непригоден!
> На самом деле с параллелизацией там всё ужасно из за GIL, который
> банально не дает нескольким тредам одновременно исполняться.
> То есть для многопоточного программирования Питон по просту непригоден!И тем не менее с многопоточным программированием парсинг сайтов намного ускоряется. Для вычислений нужно использовать многопроцессорное программирование.
>На самом деле с параллелизацией там всё ужасно из за GIL, который банально не дает нескольким тредам одновременно исполняться.Опять пришли "специалисты" прочитавшие одну статейку. GIL это механизм, который делает параллельное исполнение простым и понятным, в один момент времени исполняется один тред на
одном камне. Ничто не мешает запускать несколько тредов, или несколько процессов на разных камнях. Если есть желание самому синхронизировать потоки, и свихнуть себе мозги то питон не для тебя.
> То есть для многопоточного программирования Питон по просту непригоден!Немного не так.
GIL блокирует не потоки, а возможность параллельного исполнения кода в виртуальной машине python-а. Различие в том, что когда выполняется "тяжёлый" код в модуле написанном на C (ввод-вывод, базы данных, манипуляции матрицами и т.п.) GIL обычно снимается и потоки получают возможность исполняться параллельно.Программисты на java стараются всё затащить в java. Программисты на python время от времени находят ёмкие по времени куски и переписывают их на C.
>GIL блокирует не потоки, а возможность параллельного исполнения кода в виртуальной машине python-а.Гениально! Масло не масленое, а масленое.
> Различие в том, что когда выполняется "тяжёлый" код в модуле написанном на C (ввод-вывод, базы данных, манипуляции матрицами и т.п.) GIL обычно снимается и потоки получают возможность исполняться параллельно.
Стандартная библиотека чуть менее чем полностью написана на Си.
> Программисты на python время от времени находят ёмкие по времени куски и переписывают их на C.Раньше переписывали, сейчас есть Cython.
> Гениально! Масло не масленое, а масленое.Конечно, гениально. Если у Вас есть 100 потоков, выполняющих код типа x = x + 1,
то из-за GIL реально выполняться будет только один. А если эти 100 потоков заняты чем-то более интересным (читают/пишут файлы, пересылают данные по сети, тормошат sqlite, потрошат виндовый реестр - далее сами ищите использование макроса Py_BEGIN_ALLOW_THREADS в исходных текстах python) то GIL снимается и эффективность работы повышается.> Стандартная библиотека чуть менее чем полностью написана на Си.
Да, и Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS встречается в ней 300 раз.
Если выйти за пределы стандартной боблиотеки, то тоже можно найти примеры.
Например, в PyQt тоже применяется этот приём (и кажется даже доходит до злоупотребления)> Раньше переписывали, сейчас есть Cython.
По разному бывает. Так как Вы пишете - наверное тоже можно.
В новости вот пишут - "Переписанный на языке Си модуль "decimal" позволил до 80 раз увеличить производительность целочисленных операций". Я посмотрел код - что-то на применение Cython не похоже. В моём "мире", завязанном на Qt представляется логичным переписывать куски на С++ и создавать обвязки с помощью sip.
1. Unicode появился в Python 2.0, 12 лет назад. Поддержка его была местами лучше, местами хуже, чем в Java. С Python 3.0 стала очевидно не хуже (на Linux — лучше). С Python 3.3 — везде лучше. Прозрачно поддерживается Unicode 6.2, а Java даже Unicode 2.0 поддерживает со скрипом (и большинство разработчиков о том, как это делать, не знают).2. С параллелизацией всё хорошо, если применять подходящие инструменты для определённых задач, не хуже, чем в аналогичных языках общего назначения. Пакет multiprocessing появился в Python 2.6.
> Слышал я, что вообще в Питоне с этими вещами было паршиво. Может в этой версии уже нет?так говорили те люди которые (в ветке Пайтона версии 2.X) -- не могли отличить байтовую последовательность от юникодной строки.. [и таких людей судя по блогам -- очень много!! к сожелению.. не разобравшись, они начинали вопить в свои блоги]
в Python-2.X многие стандартные функции возвращали байтовые последовательности вместо юникодных строк.. и поэтому в Python-2.X [перед тем как использовать результат стандартных функций] требовалось обязательно сначало вручную сделать нечто вроде:
# при работе например с аргументами командной строки
u_my_result = my_result.decode(locale.getdefaultlocale()[1] or 'utf8')
# при работе с именами файлов файловой системы
u_my_result = my_result.decode(sys.getfilesystemencoding() or 'utf8')
# при работе с данными от файловых дескрипторов, например стандартный вход stdin
u_my_result = my_result.decode(getattr(my_fd, 'encoding', None) or 'utf-8')
# при получении/передаче данных по сети, и работе непосредственно с информацией (например загрузка содержимого файлов)
u_my_result = my_result.decode('utf-8') # мы же не хотим кракозябров на другом компе с другой локалью :)# ...
#
# вобщем в зависимости от того что конкретно у нас такое есть -- my_result# а кто этого не делает, и работает с байтовыми последовательнастями напрямую,
# тот в конечном итоге где-нибудь получит нежданный геморой.
# как уж после этого не отписаться на форумах-то и в блогах, о том какой якобы плохой Пайтон :-D :-Dэто было исправлено в Python-3.X -- в Python-3.X уже сразу на выходе многих стандартных функций теперь возвращается Юникодный результат (а не байтовая последовательность).
ды и вобще в Python-3.X более чётко разграничили между собой -- байтовую последовательность и юникодную строку, и теперь их стало НЕ так просто спутать между собой в отличии от того как это было в Python-2.X.. :-)
>Переписанный на языке Си модуль "decimal" позволил до 80 раз увеличить производительность целочисленных операций;А нельзя вот так вот весь Питон переписать на Си?
Нет.
Дык он на Си и написан (по крайней мере у Гвидо), толку-то...
> А нельзя вот так вот весь Питон переписать на Си?уже сделали 1991 году, с тех пор он на Си и написан.
А зачем они в 3 питоне, для print обязали ставить скобки? Новоратами 3 питона я не пользуюсь, поэтому print со скобками в питоне это бред.
Для единобразия. всетаки print это функция(да. в 3 ветке совсем функцйия)
Причём здесь единообразие? принт для отладки, зачем скобки там где их может небыть? Ну есть же операторы. Я всегда думал что print в питоне это оператор. Вот третий питон мне всё испортил. Мне нравится питон за лаконичность, а эти все новшества только удлинняют код. Питон итак довольно мощный и совершенный, зачем его портить?
Наркоман чтоль? В 3+ print() - функцииияяяя. А ВСЕ функции пишутся со скобочкааамиии...
Странно что не метод, вообще странный дизайн языка получается.
> Для единобразия.а у меня есть альтернативный ответ: потому что идиоты. вместо того, чтобы выкинуть скобки в других местах — когда они не нужны, они добавляют скобки. какая неоднозначность возникает от парзинга вызова функции с одним аргументом без скобок?
> какая неоднозначность возникает от парзинга вызова функции с одним
> аргументом без скобок?f-3
Вызов функции f с аргументом -3 или результат отнимания 3 от f?
f*a
Вызов функции с аргументами, заданными списком/кортежом a или результат умножения f на a?
А ещё вспомнить про функции без аргументов. И таких мелочей много, правила их разрешения создадут сложный и запутанный язык. Для Перла годится, для Питона — нет.
ок, уточню, mea culpa. с вызовом функции, аргумент которой — литерал: строка, массив, что там ещё можно однозначно отличить? конструкция:
print "abc"
по-моему, вполне однозначно понимается. если можно упростить синтаксис без особого геморроя и непоняток — отчего бы и да? удобно должно быть прежде всего человеку, а только потом машине.опять же, никто не мешает сделать какой-нибудь флаг strict, который отрубает подобный сахар.
в конце-концов, на гвидобейсике пишут в том числе и не особо сложные скрипты, где подобное упрощение синтаксиса более чем оправдано.
Это всё называется не «упростить синтаксис», а значительно усложнить. Для такого языка, как Питон, на котором и простые скрипты пишутся, который и неспециалисты используют, — неприемлемо.
с точки зрения парзера — усложнить. с точки зрения человека — упростить. как раз для неспециалистов.
С точки зрения пользователя — усложнить. Больше частных правил и особых случаев. Попробуйте-ка объяснить новичку, почему print 5 и print "-5" работают, а print -5 — нет. Это будет *очень* недружественный и антигуманный язык.
(вздыхает) потому что. если запомнить *опциональное* правило «вызов функции, где первый аргумент — литерал, являющийся строкой или массивом, может писаться без скобок» — офигенно сложное правило. требует IQ>200 и эйдетической памяти.
Массивы отпадают. f[2] — легальная конструкция, элемент с индексом 2 списка/кортежа f. Что остаётся?
> Массивы отпадают. f[2] — легальная конструкция, элемент с индексом 2 списка/кортежа
> f. Что остаётся?поправить синтаксис, например. инконсистентность, значит, в использовании квадратной скобки — это ничего, это гнидаванроссум благословил? тут, значит, мы можем запомнить, а бесскобочный синтаксис — не можем.
интересно было бы посмотреть на всё это, если бы гнидаванроссум ВНИЗАПНА! решил бы чуть сменить синтаксис и сделать бесскобочные вызовы. питонисты тогда бы бегали и кричали: «хорошо, хорошо-то как! питон стал ещё проще и удобней!» а пока в питоне чего-то нет — оно завсегда плохое, сложное и не нужно.
Никакой инконсистентности сейчас нет.Но вы можете форкнуть Питон (или написать с нуля) и добавить туда чего ваша душа пожелает. Хотя, конечно, ничего не делать и завистливо хаять сделанное (и хорошо сделанное!) другими некоторым нравиться больше.
(пожимает плечами) я и так пользуюсь несколькими самодельными языками, зачем мне форкать неудачную недореплику whitespace?p.s. и да, в некоторых из них есть «бесскобочный» синтаксис. после введения юзеры систем были довольны: скрипты писать стало проще.
упс а вруби все логично и print -1 => -1 и print 5-1 => 4
Руби — другой язык, у него другой синтаксис и другая логика (странные с точки многих других языков). Например, там можно сделать:print = 42
print print -1Но нельзя (что было бы естественно в Питоне):
p = print
p -1Вот поэтому в Питоне не так, как в Руби.
Ну круто но логичным я бы это не назвал. Делать ссылку оператором = на функцию.alias :p :print
p -1разве так не лаконичней, а у вас в питоне непонятно толи print переменная толи функция
Ох,
что-то мне кажется, что Вы предлагаете ядовитый сахар. Кроме простого правила нужно будет помнить ещё правила применения правила, правила отмены правила и варианты исключения из правил.Простое, дубовое правило (вызов функции - со скобочками!) упрощает жизнь как авторов парсера так и пользователей (особенно, если что-то идёт не так).
Мне вот не нравится ликвидация оператора print. Да, у него было своеобразно реализовано "перенаправление" вывода в произвольный поток. Да, запрет перевода строки после вывода выглядел "вызывающе хакерски". Кроме того поддержка оператора print требовала четырёх инструкций вирт. машины (PRINT_ITEM, PRINT_ITEM_TO, PRINT_NEWLINE и PRINT_NEWLINE_TO). Возможно, что была причина избавиться от всего этого. А так при наличии sys.stdout.write() и функция print не очень-то нужна.
> что-то мне кажется, что Вы предлагаете ядовитый сахар. Кроме простого правила нужно
> будет помнить ещё правила применения правила, правила отмены правила и варианты
> исключения из правил.зачем? я же не предлагаю скобки аннигилировать. лень помнить — можно просто ставить скобки и не заморачиваться, дел-то.
> ...какая неоднозначность возникает от парзинга вызова функции с одним
> аргументом без скобок?вот "sin x" - это хорошо и понятно.
а вот "sin 2*x" (тоже функция с одним аргументом без скобок) уже не хорошо и не понятно - это "(sin 2)*x" или "sin(2*x)"?Кроме того в случае python есть ещё одно усложнение - это мы знаем, что традиционный sin это всегда функция с одним аргументом. А компилятор python-а, бедняжечка, этого не знает.
я же уточнил, какие литералы допускать.> Кроме того в случае python есть ещё одно усложнение — это мы
> знаем, что традиционный sin это всегда функция с одним аргументом. А
> компилятор python-а, бедняжечка, этого не знает.а какая парзеру разница? есть запятая на месте терма? следующий параметр. нет запятой? конец оператора.
>> ...какая неоднозначность возникает от парзинга вызова функции с одним
>> аргументом без скобок?
> вот "sin x" - это хорошо и понятно.
> а вот "sin 2*x" (тоже функция с одним аргументом без скобок) уже
> не хорошо и не понятно - это "(sin 2)*x" или "sin(2*x)"?Если скобки строго заменять на пробелы, то "sin 2*x" эквивалентно "sin (2*x)", а вот "sin 2 *x" уже "(sin(2)*x)".
Опять же, у Руби такое используется - и ничего, компилятор-бедняжечка не путается
> Если скобки строго заменять на пробелы, то «sin 2*x» эквивалентно «sin (2*x)»,
> а вот «sin 2 *x» уже «(sin(2)*x)».в принципе, фраза «sin 2*x» человеком понимается достаточно однозначно, по-моему. а к тому, что пробелы — не просто разделители, а чуть ли не токены, питонистам не привыкать.
Свободно опускаемые скобки и куча других прелестей для опытных программистов - это perl. Питон он для другой ЦА, гибкость противоречит его философии, там шкурку с кошки можно снять строго одним образом.
> Свободно опускаемые скобки и куча других прелестей для опытных программистов - это
> perl. Питон он для другой ЦА, гибкость противоречит его философии, там
> шкурку с кошки можно снять строго одним образом.Ну у этого есть один плюс. Поддерживать код проще. И один минус. Не всем это по душе.
>Поддержка виртуальных окруженийДа здравствует version hell.
> Да здравствует version hellВы о чем, сударь? venv это хорошо и прекрасно.
>> Да здравствует version hell
> Вы о чем, сударь? venv это хорошо и прекрасно.оно не втыкнуло о чём этот самый venv эбаут :)
>> Да здравствует version hell
> Вы о чем, сударь? venv это хорошо и прекрасно.ага придумали Bundler из мира ruby. И да это прекрасно, можно искренне поздравить питонистов, теперь и им будет удобно.
>> Поддержка виртуальных окружений
> Да здравствует version hell.наверно Вы имели ввиду -- virtual-hell ! :-D
но правда мне сложно представить что это может быть такое
# p.s.: по крайней мере -- version-hell и virtual-env -- вещи вообще взаимоисключающие :)
Изменения радуют:)