Comments 147
Пишу на Питоне 6 лет, раз в год пытаюсь перейти на 3, и все никак не получается. Двойка форева.
Можете рассказать, почему все еще никак?
UFO just landed and posted this here
Так-так. Уже давно пора бы переехать с 4-5 дебиана на 6й. Это совсем не дело!
Да и 6-й Debian тоже уже старый как дерьмо мамонта, так что лучше testing ветку юзать, благо она достаточно стабильна и контроллируема.
Да зря минусуете. Парень, конечно, на язык не разборчив, но он прав. testing вполне очень даже пригодна использования. И многими используется, в том числе и для production.
Заметте, на свой страх и риск.
Да, когда дело не касается Debian, в котором свой взгляд на testing. Если немножко поутрировать, то можно перевести так:
— Debian-testing — рабочая версия,
— Debian-stable — «вылизанная», но не очень свежая версия.
По поводу сравнений Debian-testing и stable других дистрибутивов (Ubuntu и т.д.) — много писалось, вот некоторые ссылки:
— www.linux.org.ru/forum/talks/5086977
— habrahabr.ru/qa/8038/
— citkit.ru/articles/456/
— Debian-testing — рабочая версия,
— Debian-stable — «вылизанная», но не очень свежая версия.
По поводу сравнений Debian-testing и stable других дистрибутивов (Ubuntu и т.д.) — много писалось, вот некоторые ссылки:
— www.linux.org.ru/forum/talks/5086977
— habrahabr.ru/qa/8038/
— citkit.ru/articles/456/
ладно еще 5(хотя тоже ахтунг), но… 4?!?!
жесть ребята, жесть.
жесть ребята, жесть.
просто подходишь к админам и говоришь, что нужен Python X.Y. Я собрал специально Python 2.6/2.7, PyPy для CentOS 5/6 и положил в локальный репозиторий. Все отлично работает. Для CentOS достаточно пересобрать сам пайтон и setuptools.
> в которых просто нет python3.
— Ребят, ну ей Богу..., ну лучше бы не говорили… Из исходников Питон ставится за 5 минут..., тем более на Дебиан. Ну никак это не может быть «серьезной» причиной…
— Ребят, ну ей Богу..., ну лучше бы не говорили… Из исходников Питон ставится за 5 минут..., тем более на Дебиан. Ну никак это не может быть «серьезной» причиной…
Коль я уже заикнулся, то, наверное, будет уместно упомянуть коллекцию Питонов github.com/collective/buildout.python устанавливаемых через buildout.
UFO just landed and posted this here
А есть какие-нибудь интересные материалы на тему, почему стоит переходить сейчас? я помню на вторую версию тоже перешел не быстро, правда, уже не помню почему.
Меня удерживает Werkzeug, который, AFAIK, никак не может перейти на Тройку. Очень не хочется с него уходить. Если он навечно застрянет в прошлом, тогда другой вопрос.
не понятно, в чём проблема — в тройке есть и юникодные, и бинарные строки.
Потому что PyPy пока не того. А производительности хочется сейчас.
Но как только PyPy подтянется, то и смысла нет.
Ах да, еще хочется гринлетов в PyPy с JIT.
Но как только PyPy подтянется, то и смысла нет.
Ах да, еще хочется гринлетов в PyPy с JIT.
Думаю слухи о смерти python2 несколько преувеличены. И проблема, наверное, не столько в библиотеках даже, сколько в том, какую максимальную версию можно ожидать в произвольной популярной ОС/дистрибутиве без лишних телодвижений. Грубо говоря, какие возможности python должен использовать скрипт, чтобы его можно было скопипастить и он заработал на большинстве машин, где какой-то python есть.
Оооо. 1.5 наверное всех устроит.
У меня сейчас на десктопе (специально не ставил) Python 2.7.3rc2, на сервере — 2.6.6, в GAE (c недавних пор) — 2.7 можно использовать, а не так давно 2.5 максимум. Угадайте, буду ли я использовать python3 (да хотя бы 2.7) фичи в своих скриптах? И использовал ли я 2.6 фичи ещё не так давно?
Я жду осеннего релиза Django с частичной поддержкой Python 3.3.
Сам все это время буду сидеть на альфе джанги и далее и рапортовать баги и помогать пилить ее для тройки.
У меня сейчас 2.6.7, 2.7.3rc2 и 3.2.3rc2. Сам тоже ничего не ставил специально.
Сам все это время буду сидеть на альфе джанги и далее и рапортовать баги и помогать пилить ее для тройки.
У меня сейчас 2.6.7, 2.7.3rc2 и 3.2.3rc2. Сам тоже ничего не ставил специально.
Какой дистр 3.2.3 включает, если не секрет?
на production-серверах?
У меня на ноуте («Мак») — python 2.7.1. Третьего «из коробки» нет.
Всех пока устроит 2 :) Много систем в продакшене на RHEL5 и производных — питон 2.4, а новый RHEL6 перешел только на 2.6.
А учитывая десятилетний lifecycle этих систем — Python 2.x еще долго будет жить.
Не стоит забывать и про Solaris. в 10й версии только 2.4 в поставке, для Solaris 11 доступны 2.4/2.5/2.6…
Т.е. как бы не хотелю люди начать использовать версию 3.x — все упирается в отсутствие этой версии в продакшене.
ЗЫ. На десктопе стоит и 2.х и 3.х версии, но сколько бы не пробовал новую версию все равно вынуждет следовать версии 2.4, так как продакшн.
А учитывая десятилетний lifecycle этих систем — Python 2.x еще долго будет жить.
Не стоит забывать и про Solaris. в 10й версии только 2.4 в поставке, для Solaris 11 доступны 2.4/2.5/2.6…
Т.е. как бы не хотелю люди начать использовать версию 3.x — все упирается в отсутствие этой версии в продакшене.
ЗЫ. На десктопе стоит и 2.х и 3.х версии, но сколько бы не пробовал новую версию все равно вынуждет следовать версии 2.4, так как продакшн.
Тут надо отличать софт, написанный на Питоне, от копипащенного скрипта. Если человек копипастит скрипты — он если не программер, то по крайней мере продвинутый юзер, и поставить тройку сможет без проблем. Если это домохозяйка, ставящая новую софтину, то о зависимостях в любом случае должен заботиться установщик (будь то пакетный менеджер или отдельный инсталлер). А иначе имеем замкнутый круг: софт не пишем, потому что в системе только старая версия, а система не обновляется, потому что ей это не надо — все и так работает.
Я не рискую ставить тройку — боюсь, что софт и скрипты, зависящие от двойки, перестанут работать — были проблемы с другими языками, которые меняли симлинк /usr/bin/ на другой. Свои-то (и даже чужие скопипащенные) скрипты я и проверю, и перепишу если надо. Но вот даже получить список пакетов своих (используемых мною) дистров, которые зависят от python, мне что-то совсем не хочется, не говоря об их тестировании хотя бы на уровне «запустится или нет».
И поправьте меня если ошибаюсь — пакетные менеджеры питона разруливают зависимости только между модулями питона.
И поправьте меня если ошибаюсь — пакетные менеджеры питона разруливают зависимости только между модулями питона.
Проверил, после установки тройки python остается 2.7.2.
Пакетные менеджеры — я имел в виду системные. Домохозяйке pip точно до лампочки.
Мне кажется, что они весьма круто поступили, забив, с одной стороны на обратную совместимость, а с другой — сделав в двойке (пусть и только в достаточно свежей 2.7) возможность писать код, работающий и на 2.7, и на 3.
И да, у меня тоже есть сервер с 2.4, но там и все остальное — такое древнее дерьмо мамонта, что что-то туда серьезно дописывать смысла нет.
Пакетные менеджеры — я имел в виду системные. Домохозяйке pip точно до лампочки.
Мне кажется, что они весьма круто поступили, забив, с одной стороны на обратную совместимость, а с другой — сделав в двойке (пусть и только в достаточно свежей 2.7) возможность писать код, работающий и на 2.7, и на 3.
И да, у меня тоже есть сервер с 2.4, но там и все остальное — такое древнее дерьмо мамонта, что что-то туда серьезно дописывать смысла нет.
Не бойся все окей. у меня уже давно дивут 2.6/2.7/3.2 никаких проблем.
состема сама выставила питон по умолчанию и проги не конфликтуют.
а виртуальные окружения создаю с любой нужной версией питона или pypy.
У меня ubuntu 12.04 x64 если что.
состема сама выставила питон по умолчанию и проги не конфликтуют.
а виртуальные окружения создаю с любой нужной версией питона или pypy.
У меня ubuntu 12.04 x64 если что.
у руби и питона есть одно ОГРОМНОЕ отличие которое собственно и определяет его приверженцев и имя ему — синтаксис.
Ничего не понимаю. Слово «Синтаксис» должно вызывать экстаз?
Не думайте что я отвечаю только вам, просто комментарий ваш самй первый и удобнее писать тут.
У того кто пишет пару десятков лет уже так или иначе сформирован свой стиль. Питон в данном случае ярчайший пример навязывания своего стиля и синтаксиса напрямую через язык. Те кому это подуше юзают питон. Те кому это не нравится но нужен современнй скриптовый язык — юзают руби.
Синтаксис это всетаки большая часть языка программирования (вообще вам слово «язык» в этом наборе ничего не говорит?). В руби он всетаки гораздо гибче, а в остальном языки одинаковые по своей идеологии и функционалу. Выбирай, как говорится, фломастеры на свой личный вкус :)
P.S. примеров syntax sugar ruby в инете вагоносоставы, поэтому приводить не буду, но является это ключевым моментом для выберающего ЯЗЫК программирования при прочих равных или нет, решать выбирающему.
У того кто пишет пару десятков лет уже так или иначе сформирован свой стиль. Питон в данном случае ярчайший пример навязывания своего стиля и синтаксиса напрямую через язык. Те кому это подуше юзают питон. Те кому это не нравится но нужен современнй скриптовый язык — юзают руби.
Синтаксис это всетаки большая часть языка программирования (вообще вам слово «язык» в этом наборе ничего не говорит?). В руби он всетаки гораздо гибче, а в остальном языки одинаковые по своей идеологии и функционалу. Выбирай, как говорится, фломастеры на свой личный вкус :)
P.S. примеров syntax sugar ruby в инете вагоносоставы, поэтому приводить не буду, но является это ключевым моментом для выберающего ЯЗЫК программирования при прочих равных или нет, решать выбирающему.
Конечно же всё упирается в философию: идеология Python явно говорит о том, что должен быть только один путь достижения цели, тогда как Ruby напротив говорит о том, что должно быть несколько путей. Каждый выбирает то, что ему ближе, но все ведь понимают, что именно подход Python позволяет получить более поддерживаемый и чистый код в условиях современной коммерческой разработки.
Без «навязывания» определённого стиля никуда, если это не делается на уровне языка, то это делается путём различных coding style conventions/recommendations (ключевое слово «различных»). Часто «меньше» на практике выливается в «больше». И если индивидуальный разработчик может выбирать, то при работе в большой команде приходится задвинуть личные предпочтения подальше.
Без «навязывания» определённого стиля никуда, если это не делается на уровне языка, то это делается путём различных coding style conventions/recommendations (ключевое слово «различных»). Часто «меньше» на практике выливается в «больше». И если индивидуальный разработчик может выбирать, то при работе в большой команде приходится задвинуть личные предпочтения подальше.
Всё зависит от уровней разработчиков в комманде. Если в команде скил прыгает семимильными шагами от разработчика к разработчику, то без введение codestyle никуда. И как правило этот стиль навязывается более старыми (увы не всегда более квалифицированными) разработчиками.
Если же команда состоит целиком из специалистов высокой квалификации то разницу в размещении фигурных скобок и именовании переменных никто не замечает.
С годами вырабатывается привычка и DRY-ить и KISS-ить и постоянный рефакторинг (не кода ради а структурной простоты для) и короткие функции. Лично я бы навязывал именно эти практики, а не личные предпочтения одного человека, который навязал всем свой кодстайл.
Если же команда состоит целиком из специалистов высокой квалификации то разницу в размещении фигурных скобок и именовании переменных никто не замечает.
С годами вырабатывается привычка и DRY-ить и KISS-ить и постоянный рефакторинг (не кода ради а структурной простоты для) и короткие функции. Лично я бы навязывал именно эти практики, а не личные предпочтения одного человека, который навязал всем свой кодстайл.
Если синтаксис — это основной критерий, на который вы опираетесь при выборе языка, то у меня для вас плохие новости.
при выборе между питоном и руби разницы большой нет, кроме синтаксиса :) так что тут все логично.
Гкхм, [i]/me трижды поперхнулся[/i]
Ну ок, а семантика, объектная модель, особенности рантаймов никому не нужны видимо.
Ну ок, а семантика, объектная модель, особенности рантаймов никому не нужны видимо.
Для большинства задач (по количеству) это нюансы, которые зачастую даже учитывать не нужно.
Что? Это не нюансы, это основные характеристики любого ЯП! Может еще и типизацию в нюансы записать, а разделять языки по наличию semicolon'ов в конце выражений?
Для круга задач, где динамическая типизация не требуется (опять-таки, имхо, подавляющее большинство), — почему нет? Стоит задача, утрируя, написать «Hello world» для единственного пользователя, которому всё равно будет программа работать 1 мкс или 100 мс. Вы будете думать при выборе ЯП об особенностях рантаймов Python, Ruby, PHP, C++, С#, VB, Delphi, Java или JavaScript (вроде все популярные ООП языки перечислил)?
Я к чему: для большинства задач (простого количественного большинства, без учёта «веса» по сложности, нагрузки, критичности, стоимости ошибки, количеству инсталляций и т. п.) выбор языка (в рамках одной парадигмы и сравнимом количестве и качестве библиотек/фреймворков) — это вопрос вкуса, знаний, опыта и прочих фаз луны, если отбросить такие экономические параметры как популярность, рейты разработчиков, стабильность и прочее, собственно к реализации решения задачи на уровне «работает/не работает» относящееся мало.
Я к чему: для большинства задач (простого количественного большинства, без учёта «веса» по сложности, нагрузки, критичности, стоимости ошибки, количеству инсталляций и т. п.) выбор языка (в рамках одной парадигмы и сравнимом количестве и качестве библиотек/фреймворков) — это вопрос вкуса, знаний, опыта и прочих фаз луны, если отбросить такие экономические параметры как популярность, рейты разработчиков, стабильность и прочее, собственно к реализации решения задачи на уровне «работает/не работает» относящееся мало.
Вы знаете, я вот сейчас прокрутил в голове Пайтон, Гоу и Хаскель и не согласен с вами совершенно.
Фёрстворлдпроблемс, на чем написать хэллоу ворлд…
> Я к чему: для большинства задач (простого количественного большинства, без учёта «веса» по сложности, нагрузки, критичности, стоимости ошибки, количеству инсталляций и т. п.) выбор языка
У сильное ощущение, что это субъективное большинство задач — сделать сайт-визитку или лабораторная в институте, но и там и там есть предпочтительные вещи.
> вопрос вкуса, знаний, опыта и прочих фаз луны, если отбросить такие экономические параметры как популярность, рейты разработчиков, стабильность и прочее
Ну да, а время бесконечное, бюджеты резиновые, поддерживать есть кому тонны легаси-говна простите кода.
Поэтому давайте дружно брать и писать на BF. Тьюринг-полнота аллилуйа!
> Я к чему: для большинства задач (простого количественного большинства, без учёта «веса» по сложности, нагрузки, критичности, стоимости ошибки, количеству инсталляций и т. п.) выбор языка
У сильное ощущение, что это субъективное большинство задач — сделать сайт-визитку или лабораторная в институте, но и там и там есть предпочтительные вещи.
> вопрос вкуса, знаний, опыта и прочих фаз луны, если отбросить такие экономические параметры как популярность, рейты разработчиков, стабильность и прочее
Ну да, а время бесконечное, бюджеты резиновые, поддерживать есть кому тонны легаси-
Поэтому давайте дружно брать и писать на BF. Тьюринг-полнота аллилуйа!
Ну, кстати, синтаксис это действительно весомый аргумент при выборе — хотите вы этого или нет. Подобно тому, как при выборе авто весомую (а иногда и определяющую) роль играет его дизайн.
Синтаксис это то, с чем имеешь дело постоянно и ежеминутно. То что держишь «на кончиках пальцев» и оно не должно раздражать. Легло на душу или не легло.
Опять же, порог вхождения сильно влияет на распределение рынка. Почему такого бешеного успеха добился jQuery? Он настолько лучше всех аналогов? Сомнительно.
Но он предельно понятный — во всяком случае, базовые возможности. Человек, поверхностно знающий JS, открывает несколько примеров и — о чудо! — без подсказок понимает, что там происходит.
Сам я не пишу, ни на Питоне, ни на Руби. И вообще верстальщик :) Поэтому я условно-нейтральная сторона. Чисто субъективно, Питон мне кажется понятнее и как-то… естественнее.
Синтаксис это то, с чем имеешь дело постоянно и ежеминутно. То что держишь «на кончиках пальцев» и оно не должно раздражать. Легло на душу или не легло.
Опять же, порог вхождения сильно влияет на распределение рынка. Почему такого бешеного успеха добился jQuery? Он настолько лучше всех аналогов? Сомнительно.
Но он предельно понятный — во всяком случае, базовые возможности. Человек, поверхностно знающий JS, открывает несколько примеров и — о чудо! — без подсказок понимает, что там происходит.
Сам я не пишу, ни на Питоне, ни на Руби. И вообще верстальщик :) Поэтому я условно-нейтральная сторона. Чисто субъективно, Питон мне кажется понятнее и как-то… естественнее.
Питон развращает.
Теперь смотреть на C php и другие языки противно. Потому что слишком много избыточности.
Зачем эти скобки, точки с запятыми? Эти заявления типов и т.п. и т.д.
jquery спасает в яваскрипте похожей простотой.
Вот и все.
Теперь смотреть на C php и другие языки противно. Потому что слишком много избыточности.
Зачем эти скобки, точки с запятыми? Эти заявления типов и т.п. и т.д.
jquery спасает в яваскрипте похожей простотой.
Вот и все.
Руби всё же более логичный и продуманный. Нет странных синтаксисов с квадратными скобками или там с кверхногамизаписанными join-ами :)
Данные языки решают одни и те же вопросы, иногда разными тропинками, поэтому выбор остается, скажем так, за стилем программирования — будет более правильно.
Спасибо. Про codecs.open — действительно, запамятовал :(. Убрал этот пункт.
По поводу OpenSSL — вы скорее всего путаете OpenSSL как библиотеку и SSL как протокол соединения поверх TCP. SSL действительно есть и ставится ActiveState. OpenSSL штатного нету, нужно ставить поделки вида M2Crypto или pyopenssl. Вот недалее как вчера в M2Crypto багу нашел вида «ничего не работает».
По поводу subprocess и shell — я уже писал, это не работает ни в каких комбинациях если мы под windows и пробелы случились одновременно в пути к программе и в одном из аргументов. Смиритесь — в system() из CRT это тоже не работает. А в Ruby — работает.
Импорт по относительному пути — это когда у нас есть PATH в котором ищем common и оттуда грузим. Питон так не может. То что он может импортировать специальным образом оформленную подпапку — это не совсем то.
По поводу потоков — это даже Qt может, который вообще C++. Ничего сложного если «главный цикл» в потоке крутим мы сами. Для ресурсов есть деструкторы / счетчики ссылок.
Ну а про сторонние библиотеки тоже соглашусь, но я сразу написал что если их сравнивать — то статья лопнет как та корова. Да и компетенции мне не хватит.
По поводу OpenSSL — вы скорее всего путаете OpenSSL как библиотеку и SSL как протокол соединения поверх TCP. SSL действительно есть и ставится ActiveState. OpenSSL штатного нету, нужно ставить поделки вида M2Crypto или pyopenssl. Вот недалее как вчера в M2Crypto багу нашел вида «ничего не работает».
По поводу subprocess и shell — я уже писал, это не работает ни в каких комбинациях если мы под windows и пробелы случились одновременно в пути к программе и в одном из аргументов. Смиритесь — в system() из CRT это тоже не работает. А в Ruby — работает.
Импорт по относительному пути — это когда у нас есть PATH в котором ищем common и оттуда грузим. Питон так не может. То что он может импортировать специальным образом оформленную подпапку — это не совсем то.
По поводу потоков — это даже Qt может, который вообще C++. Ничего сложного если «главный цикл» в потоке крутим мы сами. Для ресурсов есть деструкторы / счетчики ссылок.
Ну а про сторонние библиотеки тоже соглашусь, но я сразу написал что если их сравнивать — то статья лопнет как та корова. Да и компетенции мне не хватит.
UFO just landed and posted this here
UFO just landed and posted this here
Есть прекрасный пост на эту тему Как устроен GIL в Python
Я тоже прошлым летом довольно подробно расписывал, как именно работает GIL и как он не работает, что бы кто не думал: asvetlov.blogspot.com/2011/07/gil.html
Не правы, питновские потоки — это «настоящие» потоки, они не выполняются в одном системном потоке.
Если вам важен именно OpenSSL — то да, его нет. Мне показалось, что речь шла именно об отсутствии поддержки ssl Питоном. Извиняюсь, вышло недопонимание.
Пробелы и shell. Я не увидел слово «Windows». На posix пробелы обрабатываются корректно.
Я не очень хорошо знаком с импортом в Ruby. Помню только, что там указываются файлы. Питон работает с модулями. Видно, это источник нашего недопонимания. В Питоне можно делать импорт модуля по относительному пути в пространстве имен модулей. Импортировать файл нельзя по дизайну языка (долгое время сидел коварный баг, который такое безобразие всё же разрешал — потом его таки нашли и изничтожили).
А вот по поводу потоков совсем не соглашусь.
— Главный цикл в потоке мы сами крутим далеко не всегда. Более того, не всегда главный цикл в потоке вообще есть. Как всё ещё нет и определения/стандарта для главного цикла если он всё же присутствует. У Qt свой главный цикл, а у twisted или tornado — свой…
— Если поток подвис на выполнении кода C Extension — его можно прибить (pthread_kill/TerminateThread). Но освободить ресурсы не получится. Не все ресурсы зарегистрированы в Питоне — некоторые могут принадлежать С Extension. Создавать объект в одном потоке, а деструкторы иногда запускать в другом — не самый чистый дизайн. Не весь код покорно снесет подобное издевательство.
— Если же у нас есть свой главный цикл потока, который работает устойчиво и не блокируется надолго — нет никаких сложностей в явной отсылке сигнала этому циклу с просьбой завершиться. Во всех прочих случаях проблема не решается в общем виде.
Пробелы и shell. Я не увидел слово «Windows». На posix пробелы обрабатываются корректно.
Я не очень хорошо знаком с импортом в Ruby. Помню только, что там указываются файлы. Питон работает с модулями. Видно, это источник нашего недопонимания. В Питоне можно делать импорт модуля по относительному пути в пространстве имен модулей. Импортировать файл нельзя по дизайну языка (долгое время сидел коварный баг, который такое безобразие всё же разрешал — потом его таки нашли и изничтожили).
А вот по поводу потоков совсем не соглашусь.
— Главный цикл в потоке мы сами крутим далеко не всегда. Более того, не всегда главный цикл в потоке вообще есть. Как всё ещё нет и определения/стандарта для главного цикла если он всё же присутствует. У Qt свой главный цикл, а у twisted или tornado — свой…
— Если поток подвис на выполнении кода C Extension — его можно прибить (pthread_kill/TerminateThread). Но освободить ресурсы не получится. Не все ресурсы зарегистрированы в Питоне — некоторые могут принадлежать С Extension. Создавать объект в одном потоке, а деструкторы иногда запускать в другом — не самый чистый дизайн. Не весь код покорно снесет подобное издевательство.
— Если же у нас есть свой главный цикл потока, который работает устойчиво и не блокируется надолго — нет никаких сложностей в явной отсылке сигнала этому циклу с просьбой завершиться. Во всех прочих случаях проблема не решается в общем виде.
Да, у меня на posix тоже все работало. А потом когда развернул в production на несколько сотен — начался подземный стук. Сначало локализовалось что это Windows. Потом пробелы. Ну и наконец — пробелы в имени программы и одного из ее аргументов. Токая неконсистентность довольно болезнена для кроссплатформенной разработки :(.
На мой профессиональный взгляд, преимущество относительного импорта не в том что там импортится — файлы/модули/whatever, а в том, что для сложной программы мы можем вынести некий модуль/часть программы в папку «common» и импортить ее из вложенных папок — даже из тех, которые находятся «ниже» папки common в иерархии файловой системы. Ruby это позволяет сделать в одну команду, питон — в много команд со спецэффектами. Это различие, я его подчеркнул. И да, я знаю много способов организации исходных кодов и разделения программ на компоненты — в ряде случаев, действительно, за глаза хватает функциональности питона. Но не всегда ©.
Питон — язык, работающий поверх виртуальной машины. Поэтому код питона, который выполняется в потоке всегда можно остановить, не нарушая физической целостности программы. Безусловно, если все что делает поток — это вызывает внешнюю функцию через FFI, то остановить его средствами языка действительно логически затруднительно. Но в общем случае, если в потоке выполняется код питона — числодробилка, или пинг в цикле — то остановка такого потока средствами языка — вполне себе штатная операция. Для небольших, но многопоточных утилит такая возможность на уровне стандартной библиотеки — это, на мой взгляд, достаточно большой плюс, чтобы я его вынес в сравнение :)
На мой профессиональный взгляд, преимущество относительного импорта не в том что там импортится — файлы/модули/whatever, а в том, что для сложной программы мы можем вынести некий модуль/часть программы в папку «common» и импортить ее из вложенных папок — даже из тех, которые находятся «ниже» папки common в иерархии файловой системы. Ruby это позволяет сделать в одну команду, питон — в много команд со спецэффектами. Это различие, я его подчеркнул. И да, я знаю много способов организации исходных кодов и разделения программ на компоненты — в ряде случаев, действительно, за глаза хватает функциональности питона. Но не всегда ©.
— Главный цикл в потоке мы сами крутим далеко не всегда. Более того, не всегда главный цикл в потоке вообще есть. Как всё ещё нет и определения/стандарта для главного цикла если он всё же присутствует. У Qt свой главный цикл, а у twisted или tornado — свой…
Питон — язык, работающий поверх виртуальной машины. Поэтому код питона, который выполняется в потоке всегда можно остановить, не нарушая физической целостности программы. Безусловно, если все что делает поток — это вызывает внешнюю функцию через FFI, то остановить его средствами языка действительно логически затруднительно. Но в общем случае, если в потоке выполняется код питона — числодробилка, или пинг в цикле — то остановка такого потока средствами языка — вполне себе штатная операция. Для небольших, но многопоточных утилит такая возможность на уровне стандартной библиотеки — это, на мой взгляд, достаточно большой плюс, чтобы я его вынес в сравнение :)
Пробелы и subprocess: создайте баг в bugs.python.org
Будет совсем здорово, если он будет с тестом и патчем. Это же OpenSource!
Импорты — давайте замнем для ясности.
Потоки. Еще раз: вы приводите частные случаи, где остановка потока полезна и безопасна. Но существует слишком много вариантов, которые не вписываются в предложенную схему. Поэтому Питон и не имеет стандартной возможности принудительного завершения потока.
Будет совсем здорово, если он будет с тестом и патчем. Это же OpenSource!
Импорты — давайте замнем для ясности.
Потоки. Еще раз: вы приводите частные случаи, где остановка потока полезна и безопасна. Но существует слишком много вариантов, которые не вписываются в предложенную схему. Поэтому Питон и не имеет стандартной возможности принудительного завершения потока.
Попытки оградить программиста от «потенциально опасных» вещей — это, безусловно, хорошо. Но снижает лаконичность и гибкость языка. Проблема сложности, complexity problem — зверек не белый и пушистый. Подкрадывается незаметно, откусывает сразу голову. Все мы помним чем закончилась попытка сделать «безопасный для программиста» язык, Java. И какие к нему основные претензии.
После нашей переписки и обсуждения вопроса с коллегами я пересмотрел свою позицию.
Возможно, вам будет интересно посмотреть на дискуссию, которую я поднял на python-ideas в теме Thread stopping. Голосуйте за предложение, что ли…
Возможно, вам будет интересно посмотреть на дискуссию, которую я поднял на python-ideas в теме Thread stopping. Голосуйте за предложение, что ли…
Спасибо. Рад, что моя позиция достаточно разумна, чтобы привлекать сторонников естественным образом. Попробую добавить в копилку и свой голос :)
BTW, я думаю stop() было бы более идеоматично, нежели interrupt. Во-первых, это во всех остальных языках называется stop. Во-вторых, interrupt подразумевает resume, а остановка потока, насколько я понимаю, подразумевает что он после этого останавливается.
Кстати pypy пока тройку еще не поддерживают. А так мы конечно все на тройку согласны.
Deepwalker, специально для тебя.
Гвидо спросил: Кто использует pypy в production? Несколько рук. Кто использует cpython? 2000+
И кому интерессна эта pypy? Замечательный проект, к слову.
Гвидо спросил: Кто использует pypy в production? Несколько рук. Кто использует cpython? 2000+
И кому интерессна эта pypy? Замечательный проект, к слову.
«Интересен» и «Использует в продакшн» — это два разных понятия: многим интересен pypy (ведь они смотрят на впечатляющие графики), но его ещё очень не скоро рискнут использовать в продакшне.
И раз уж вы Python Core Developer, подскажите пожалуйста, почему в datetime.timedelta нет такой очевидной вещи, как months (и years), приходится ради такой мелочи либо ставить стороннюю библиотеку, либо писать велосипед.
И раз уж вы Python Core Developer, подскажите пожалуйста, почему в datetime.timedelta нет такой очевидной вещи, как months (и years), приходится ради такой мелочи либо ставить стороннюю библиотеку, либо писать велосипед.
Кстати, этот сайт использует pypy seatgeek.com/
не думаю, что это не так уж и очевидно, но имхо дело в том, что в months и years — это не константные величины, то есть, в месяцах и годах вполне может быть разное кол-во дней, вы хотите чтобы питон сам высчитывал?:) и как? timedelta(months=1) прибавлять 28/29/30/31 день месяца? или вы хотите просто менять циферку месяца?
Да, конечно понятно, что речь идет не об абсолютной, а относительной дельте. Речь идёт именно о смене цифры месяца (но с учетом количества дней в итоговом месяце). Почему не очевидно, разработчикам сторонних библиотек очевидно же…
пятый час, перемудрил, хотел сказать, что это достаточно очевидно. На самом деле, я модулем datetime пользуюсь чаще всего, я бы даже сказал, что каждый день и уже очень давно. Я такой проблемы не испытываю, сталкивался один или два раза, по-моему, с такой задачей. Думаю, что это как раз дело какого-нибудь стороннего модуля.
timedelta — это просто ещё один вариант записи относительной даты, не меняющий арифметических свойств (коммутативность, например). Для года и месяца это нарушается, поэтому в библиотеке специально и не реализовано.
Типичный пример:
а теперь наоборот
Типичный пример:
29.jan.2011 + 1 year + 1 month = 29.feb.2012а теперь наоборот
29.jan.2011 + 1 month + 1 year = 28.feb.2012
> почему в datetime.timedelta нет такой очевидной вещи как months (и years)
Потому, что в общем случае она для _интервалов_ времени невозможна.
Потому, что в общем случае она для _интервалов_ времени невозможна.
Вобщем как говорят некоторые программисты(которые знают и руби и питон): если выбираешь между руби и питоном то ты точно не ошибешься. Холиварить можно до усрачки хоть каждый день и никчему не прийти.
Лично мне нравится питон. На нем я могу быстро написать хоть сайт, хоть прогу с гуевиной(или без) или приложение для iPhone да и добрая половина моей родимой бубунты написана на питоне и я могу все менять итд. Почему не на руби а на питоне? почему питон стоит в каждом почти линуксе и маке а руби нет?
В конце концов язык программирования это язык на котором мы говорим с машиной. И мы выбираем тот язык на котором нам приятнее и удобнее говорить, кто-то малословный и любит коротко и ясно… кто-то любит поболтать — пожалуйста другой язык. кто-то любит разжевать все до мелочей — третий. итд… под каждую задачу своя интонация и язык… Ну я утрирую канешно)) не кидайтесь камнями.
Лично мне нравится питон. На нем я могу быстро написать хоть сайт, хоть прогу с гуевиной(или без) или приложение для iPhone да и добрая половина моей родимой бубунты написана на питоне и я могу все менять итд. Почему не на руби а на питоне? почему питон стоит в каждом почти линуксе и маке а руби нет?
В конце концов язык программирования это язык на котором мы говорим с машиной. И мы выбираем тот язык на котором нам приятнее и удобнее говорить, кто-то малословный и любит коротко и ясно… кто-то любит поболтать — пожалуйста другой язык. кто-то любит разжевать все до мелочей — третий. итд… под каждую задачу своя интонация и язык… Ну я утрирую канешно)) не кидайтесь камнями.
Да и есть же стереотипы, которые доносят евангелисты, есть экосистема и приоритетные фреймворки. Первые мои ассоциации с Ruby: культовый Rails, аура Apple и Mac OS, трендовый GitHub, стартапы — всё это сильно действует на «хипстерское» сознание. Python гораздо более академичен, шире применяется, настоящий и полноценный мейнстрим не только для веба. Пусть и не отражающие возможности языка, эти представления всё равно в конечном счёте следуют из особенностей, преимуществ и сообществ вокруг этих двух замечательных языков. Это как сравнивать iPhone и Android без маркетинга. Где искать различия в интерфейсе, в доступном API, внешнем виде и доступных приложениях можно до бесконечности.
за хипстерским сознанием кроются мощные технологические скиллзы а вся эта напыщенная академичность вызывает рвоту.
как же хорошо, что не все рубисты такие тролли
Не твои ли слова служили мотивом к тем нашумевшим действиям по показу уязвимости рельс на гитхабе, слова о том, что большая часть тех, кто пишет на ruby on rails в основном люди с поверхностными знаниями? :)
А так согласен — везде есть свои хакеры и свои ботаны. Но твой стереотип понятен, это как раз то о чем я и говорил.
А так согласен — везде есть свои хакеры и свои ботаны. Но твой стереотип понятен, это как раз то о чем я и говорил.
В частности, он указал что Питон и Руби — почти что близнецы-братья.
Если я правильно помню, то Гвидо в своей речи разделил языки по проблемным областям и уровням абстракций, при этом вышло, что python-ruby-perl образуют суть один пласт. С такой его трактовкой сложно не согласиться. А вот про близнецов не вспомню.
Python, and Ruby, and Perl are exactly the same language.
www.youtube.com/watch?feature=player_detailpage&v=EBRMq2Ioxsc#t=351s
И там не про проблемные области и абстракции, а про принципы устройства языка и его коммунити. На ту же полочку он положил и Lisp.
www.youtube.com/watch?feature=player_detailpage&v=EBRMq2Ioxsc#t=351s
И там не про проблемные области и абстракции, а про принципы устройства языка и его коммунити. На ту же полочку он положил и Lisp.
Только не кастрируйте цитату, ведь в оригинале она не просто так начинается с ремарки про 10 км.
Вот эти 10 км — абстракция, позволяющая судить об уровне сходства/различия языков. И, таки да, сообщества — дополнительный частный пример сходности. Опять же, если не забывать про 10 км.
Из контекста можно судить, что речь идёт, как раз о разделении языков по областям и уровням.
К сожалению не могу прокомментировать замечание про «принципы устройства языка», т.к. не понимаю что вы имеете ввиду под этим словосочетанием %)
Поднимитесь на 50 км, и вы увидите, что все языки программирования сходны, с сотни км можно будет говорить об одинаковости любых языков и о том, что все люди братья.
Вот эти 10 км — абстракция, позволяющая судить об уровне сходства/различия языков. И, таки да, сообщества — дополнительный частный пример сходности. Опять же, если не забывать про 10 км.
Из контекста можно судить, что речь идёт, как раз о разделении языков по областям и уровням.
К сожалению не могу прокомментировать замечание про «принципы устройства языка», т.к. не понимаю что вы имеете ввиду под этим словосочетанием %)
Поднимитесь на 50 км, и вы увидите, что все языки программирования сходны, с сотни км можно будет говорить об одинаковости любых языков и о том, что все люди братья.
А 10 км это много или мало с точки зрения Гвидо? ;) Может быть это как раз высота достаточная для того чтобы абстагироваться от синтаксиса, некоторых нюансов и особенностей устройства ООП.
Ну ок, динамическая типизация, ключевое свойство языка. Исходя из этой характеристики строится весь язык, начиная с низов, заканчивая самыми высокими абстракциями. Поэтому clojure куда ближе к руби / питону, хоть и функциональная, чем Scala, которая, вроде как, куда больше похожа на обычные программы на руби и питоне.
Если говорить о моем личном мнении, то я вижу достаточно различий между руби и питоном, как в языках, так и в коммунити, что бы отдать предпочтение одному из них, не скажу какому. А цитату привел, потому что фраза «Питон и Руби — почти что близнецы-братья», все же не так уж далека от того, что сказал Гвидо ;)
Ну ок, динамическая типизация, ключевое свойство языка. Исходя из этой характеристики строится весь язык, начиная с низов, заканчивая самыми высокими абстракциями. Поэтому clojure куда ближе к руби / питону, хоть и функциональная, чем Scala, которая, вроде как, куда больше похожа на обычные программы на руби и питоне.
Если говорить о моем личном мнении, то я вижу достаточно различий между руби и питоном, как в языках, так и в коммунити, что бы отдать предпочтение одному из них, не скажу какому. А цитату привел, потому что фраза «Питон и Руби — почти что близнецы-братья», все же не так уж далека от того, что сказал Гвидо ;)
> уничтожить поток.… Поэтому Питон и не имеет такой возможности.
Я считаю, что реализовать функцию (в ядре питона) уничтожения потока не тяжело, её специально не делают — как бы подталкивают к правильной разработке программ. Т.е. это скорее является «фичей» чем «минусом».
Я считаю, что реализовать функцию (в ядре питона) уничтожения потока не тяжело, её специально не делают — как бы подталкивают к правильной разработке программ. Т.е. это скорее является «фичей» чем «минусом».
ждем ответ на ответ от рубиста
Вы уж как-нибудь отпинайте там Django, чтобы она не «обещала», а делала. Потому что тройку хочется, но что толку если в моем случае там нельзя сделать добрые 2/3 того, что в двойке.
В этом году уже будет экспериментальная поддержка Python 3.3
Полуофициальный форк с поддержкой 3го питона ( bitbucket.org/vinay.sajip/django ) давно есть, он регулярно мерджится с апстримом и его скоро влить должны в транк. Лучше не пинать, а помогать — ставьте его, пробуйте, исправляйте, что не работает. Кого пинать-то? Над джангой точно такие же люди работают, по своей инициативе, никто им за это ничего не платит, за что их пинать-то.
Не вижу смысла в этом довольно старом споре, большинство делает выбор решающим фактором которого становится синтаксис, а потом все остальное.
Сама тема аналогична убеждению кого-либо в сексуальном предпочтении, кому-то нравятся девочки, кому-то мальчики, если человек имеет твердое убеждение, то никакие факты не помогут. Тоже и касается вопроса выбора Python vs RuBy.
Сама тема аналогична убеждению кого-либо в сексуальном предпочтении, кому-то нравятся девочки, кому-то мальчики, если человек имеет твердое убеждение, то никакие факты не помогут. Тоже и касается вопроса выбора Python vs RuBy.
Андрей!
А можешь выступить с этим анализом на секции DevConf::Ruby?
devconf.ru/offers/ruby
А рубисты сделали бы ответный алаверды на питонячей секции?
А можешь выступить с этим анализом на секции DevConf::Ruby?
devconf.ru/offers/ruby
А рубисты сделали бы ответный алаверды на питонячей секции?
А кто потом будет разнимать?
Да какой же это анализ? И что мне делать у Рубистов?
Давайте я вам лучше расскажу, чем Python3 лучше Python2. Тоже наваристый холивар для тех, кто понимает.
Давайте я вам лучше расскажу, чем Python3 лучше Python2. Тоже наваристый холивар для тех, кто понимает.
Андрей, лучше расскажите про SSL и subprocess. А то как-то неудобно получается — написали громкое опровержение, написали что я не знаю матчасть — а после того, как я внимательно все изучил и задал уточняющие вопросы — тишина, спокойствие. Мне же тоже интересно — может, действительно subprocess работает, SSL и OpenSSL — одно и тоже, а Qt останавливает потоки волшебным образом? :)
Андрей, да! Мне кажется сейчас самое время для такого рассказа.
По моему опыту в переходе Py2 на Py3 самая большая проблема это юникод (за ногу его) — В Py2 — str это bytes в Py3 — и это делает много… нет МНОООГО геморроя.
Вот сейчас буквально копаю
В freeswitch библиотека эвентов интерфейсится на Питон используя генератор SWIG. В генерированной либе при поступленнии эвента Exception возникает в c++ коде — который пытается отдавать мне (если я юзаю Py3) — PyUnicode вместо PyString для Py2. — ручками я добрался и заменил его на PyBytes — Но ребята (коре питоновцы) — строки — это то что мы все используем и такие изменения нужно делать както по-другому, чтобы это не ломало все и вся. (я не про SWIG а про изменение str — bytes)
И такие примеры с юникодом на каждом шагу и в куда более простых применениях.
Вот сейчас буквально копаю
В freeswitch библиотека эвентов интерфейсится на Питон используя генератор SWIG. В генерированной либе при поступленнии эвента Exception возникает в c++ коде — который пытается отдавать мне (если я юзаю Py3) — PyUnicode вместо PyString для Py2. — ручками я добрался и заменил его на PyBytes — Но ребята (коре питоновцы) — строки — это то что мы все используем и такие изменения нужно делать както по-другому, чтобы это не ломало все и вся. (я не про SWIG а про изменение str — bytes)
И такие примеры с юникодом на каждом шагу и в куда более простых применениях.
Мысли о Python3 от автора Jinja2 — http://lucumr.pocoo.org/2011/12/7/thoughts-on-python3/
UFO just landed and posted this here
Дизайн его блогов и докладов многим нравится. Есть тема оформления для sphinx, которую сейчас ставят все подряд.
Но в общем дизайн это же так. Что мне нравится гораздо больше в Армине, это что за написанием кода, хорошего на мой вкус, хоть и не все его идеи удачны, он не забывает писать прекрасную документацию, ясно и доступно выражая свои мысли. Я вот пока так не могу. Донести до хабра прелести trafaret я так и не смог, по всей видимости.
Но в общем дизайн это же так. Что мне нравится гораздо больше в Армине, это что за написанием кода, хорошего на мой вкус, хоть и не все его идеи удачны, он не забывает писать прекрасную документацию, ясно и доступно выражая свои мысли. Я вот пока так не могу. Донести до хабра прелести trafaret я так и не смог, по всей видимости.
Интересно было бы услышать мнение человека солюшен архитектора. Когда при старте проекта следует выбирать руби, а когда пайтон.
Ruby is full of love.
Python isn't.
Python isn't.
попробовал поставить под python 3 пакеты проекта, половина пакетов пока не собирается :(
впрочем я не особо тщательно пытался, возможно с бубном получится их завести.
и возможно помогу с переводом каких-нибудь на python 3 если руки дойдут.
а так очень ждем эти:
Flask, Werkzeug, Pillow, WTForms, webassets, redis, hiredis, gunicorn, pytils, gevent, ujson, raven, bleach.
впрочем я не особо тщательно пытался, возможно с бубном получится их завести.
и возможно помогу с переводом каких-нибудь на python 3 если руки дойдут.
а так очень ждем эти:
Flask, Werkzeug, Pillow, WTForms, webassets, redis, hiredis, gunicorn, pytils, gevent, ujson, raven, bleach.
Поддержку 3го питона мы в pytils на www.ekbpy.ru/ добавили ( github.com/kmike/pytils ), но там потом репозитории немного разошлись, смерджить руки ни у кого не дошли. Форк должен работать под питонами с 2.6 по 3.2.
WTForms и hiredis используем без проблем.
gunicorn будет — на PyCon David Beazley публично застыдил Benoit Chesneau и последний пообещал таки портировать.
gunicorn будет — на PyCon David Beazley публично застыдил Benoit Chesneau и последний пообещал таки портировать.
о, здорово, попробую повозиться и завести их :)
ждем gunicorn :)
ждем gunicorn :)
ах, еще SQLAlchemy таки не до конца использует :(
без нее никуда…
SQLAlchemy includes C extensions which provide an extra speed boost for dealing with result sets. Currently, the extensions are only supported on the 2.xx series of cPython, not Python 3 or Pypy.
без нее никуда…
SQLAlchemy includes C extensions which provide an extra speed boost for dealing with result sets. Currently, the extensions are only supported on the 2.xx series of cPython, not Python 3 or Pypy.
Всё-таки основное различие в философии:
Pyhon: There should be one — and preferably only one — obvious way to do it.
Ruby: I'd rather provide many ways if it's possible, but encourage or guide users to choose a better way if it's possible.
Pyhon: There should be one — and preferably only one — obvious way to do it.
Ruby: I'd rather provide many ways if it's possible, but encourage or guide users to choose a better way if it's possible.
Чем больше похожи языки, тем больший это повод для холивара. Наиболее сильные межвидовые столкновения происходят у близких видов (в биологии).
Когда GIL выпилите?
Когда GIL выпилите?
Еще очень нескоро. Судя по тому, что регулярно возникают выпиливающие движения, довольно быстро сдувающиеся.
Скорее всего, в Руру справлятся с GIL быстрее чем в CPython, с помощью transactional memory. Не хотите GIL сейчас — попробуйте Jython.
Ну-ну. Еще одна вандервафля.
Если transaction memory выстрелит — отлично. Как по мне, это идеологически хороший подход, который обрывается на IO.
Я три года назад много работал с PEAK trellis а потом с переработкой от Сергея Щетинина. Общее впечатление: идея хороша, но не вполне ложится на привычные представления. И как решить вопрос один раз и для всех — не представляю. Слишком много побочных эффектов. Если у Риго из PyPy получится — буду очень рад. В любом случае внимательно слежу за развитием.
Если transaction memory выстрелит — отлично. Как по мне, это идеологически хороший подход, который обрывается на IO.
Я три года назад много работал с PEAK trellis а потом с переработкой от Сергея Щетинина. Общее впечатление: идея хороша, но не вполне ложится на привычные представления. И как решить вопрос один раз и для всех — не представляю. Слишком много побочных эффектов. Если у Риго из PyPy получится — буду очень рад. В любом случае внимательно слежу за развитием.
GIL не сломан — не надо его чинить. Практика показывает, что пользы от него больше, чем вреда. Те редкие случаи, когда нужен параллелизм логики, например числодробилки — делаются процессами.
Sign up to leave a comment.
Ответ на Python vs Ruby