Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
Сообщение от opennews (ok), 31-Дек-13, 10:56
Алекс Гейнор (Alex Gaynor), один их ключевых разработчиков CPython и Django, входящий в совет директоров организации Python Software Foundation, выразил (http://alexgaynor.net/2013/dec/30/about-python-3/) опасение, что после 5 лет существования ветка Python 3 до сих пор не получила должного распространения. Первый стабильный выпуск Python 3.0 был опубликован ещё в декабре 2008 года, но с тех пор интенсивность перевода проектов на Python 3 оставляет желать лучшего. Например, в каталоге Python Package Index (https://pypi.python.org/pypi) с Python 3 связано всего 2% загрузок пакетов. Более того, почти не создано кода, работающего только с Python 3. Такие проекты как Django, добавившие поддержку Python 3, продолжают вести первичную разработку и тестирование с использованием Python 2, попутно проверяя работоспособность в Python 3 через средства непрерывной интеграции. Ни одна опрошенная крупная компания, развивающая проекты на языке Python, не использует специфичный для Python 3 код и не планирует миграцию кодовой базы на Python 3. В качестве основной причины низких темпов перехода на Python 3 упоминается продолжение параллельного развития ветки Python 2, что привело к отсутствию стимула перехода на Python 3 - при должной поддержке  Python 2 и отсутствии мотивов для срочного перехода на  Python 3, разработчики приложений могут бесконечно откладывать миграцию, оставляя данную задачу в качестве низкоприоритетных планов. В качестве второй причины называется отсутствие у разработчиков интереса к ветке Python 3, которая не содержала кардинальных прорывных улучшений, которые могли бы подтолкнуть людей к внедрению новой ветки.  В частности, Python 3 не сдвинулся вперёд  в таких  востребованных областях, как уход от глобальной блокировки (GIL, Global Interpreter Lock) и заметное повышение производительности. Вместо этого в Python 3 был расширен стандартный набор библиотек и проведена чистка проблемных мест, которые опытные разработчики уже научились обходить по привычке. В итоге, 99% разработчиков не используют новшества Python 3 и прекрасно обходятся без них. В свою очередь, недостаточный объем внедрений рабочих решений на базе Python 3 приводит к проблемам с полноценным тестированием добавляемых новшеств в реальных проектах, что сказывается на ухудшении качества кодовой базы  Python 3.x. В качестве одного из выходов из сложившегося тупика предлагается выпустить ветку Python 2.8, в которую бэкпортировать все новшества из Python 3, в том числе объявить устаревшими возможности, для которых нельзя обеспечить обратную совместимость (например, выводить предупреждение при использовании str + unicode), что подтолкнёт разработчиков к адаптации новых возможностей. URL: http://alexgaynor.net/2013/dec/30/about-python-3/ Новость: http://www.opennet.me/opennews/art.shtml?num=38761
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
Сообщение от бедный буратино (ok), 31-Дек-13, 10:56
> В качестве основной причины низких темпов перехода на Python 3 упоминается продолжение параллельного развития веток Python 2.x/3.x, что привело к отсутствию стимула перехода на Python 3 - при должной поддержке Python 2 и отсутствии мотивов для срочного перехода на Python 3 а ПОЧЕМУ люди должны переходить на python 3, собственно? - python 2 почти идеален :) - python 2 уже работает, и работает замечательно - python 2 стабилен, как железобетон, никаких изменений в ближайшие 1000 лет не предвидится - python 2 банально быстрее Назовите новый язык "тритон", и кто захочет - пусть мигрирует. Кто не захочет - пусть пользуется ридным питоном.
Ответить | Правка | Наверх | Cообщить модератору

	8. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+28 +/–
	Сообщение от Аноним (-), 31-Дек-13, 11:19
	Поддержка последней версии python2.7 закончится через год, рискуешь остаться с устаревшими знаниями. Алекс Гейнор молодой юнец, среди основных его работ аля "курсовые" экспериментальные работы по созданию jit-компилятора Руби и т.п. Одним из нововведений python3 - это конструкция yield from и находящийся в бэте новый модуль asyncio(в архитектуре которого принимали участие создатели twisted,tornado..) и дополнительные средства отладки. IMO, Его предложение крайне ошибочно. Язык должен постепенно эволюционировать, к сожалению сейчас уже поздно вводить новые версии, тот же RHEL7, Debian Wheezy уже имееют при старте поддержку Python3. Django в будущем планирует оставить LTS выпуск для python2, все новые фичи будут только с PYTHON3. Core Django Dev, Aymeric Augustin постоянно проводит тесты с новыми возможностями представленными в Python3. [сообщение отредактировано модератором]
	Ответить | Правка | Наверх | Cообщить модератору

	11. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+3 +/–
	Сообщение от Аноним (-), 31-Дек-13, 11:28
	продолжение.. я считаю что всё идет своим чередом, попутно вылизываются недочеты python3, в частности если смотреть на версию python3.3.3, и перешедшие на питон3 (python3.3.3 и позднее) уже увидят логичный и выверенную кодовую базу. Если же python3.4 станет быстрее 2.7 хотя бы на 10-15% - это будет не маловажным толчком к массовому переходу. Мне кажется такое способны сделать только представители научной части пользователей Python.
	Ответить | Правка | Наверх | Cообщить модератору

	25. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+2 +/–
	Сообщение от all_glory_to_the_hypnotoad (ok), 31-Дек-13, 12:06
	> Мне кажется такое способны сделать только представители научной части пользователей Python. Совсем сдупел. Они же в большей части нубы и дубы в разработке. Эта проблема исключительно мейнтейнеров CPython и Гвиды лично. Находятся же кадры, которые пишут с нуля PyPy, а задача оптимизации CPython несколько легче.
	Ответить | Правка | Наверх | Cообщить модератору

	30. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–2 +/–
	Сообщение от бедный буратино (ok), 31-Дек-13, 12:49
	SciPy NumPy и иже с ними ipython, и с ним же sage-mathematics
	Ответить | Правка | Наверх | Cообщить модератору

	35. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+2 +/–
	Сообщение от all_glory_to_the_hypnotoad (ok), 31-Дек-13, 13:04
	это не оптимизация, а в основном привязка существующих пакетов к питону. Оригинальной логики и тем более хардкорной оптимизации там почти нет.
	Ответить | Правка | Наверх | Cообщить модератору

	40. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–4 +/–
	Сообщение от Аноним (-), 31-Дек-13, 13:28
	> SciPy > NumPy > и иже с ними ipython, и с ним же sage-mathematics ...которые в основном биндинги для самых глупеньких к сишным либам. Вот ученые, которые в программировании ни бум-бум и получили возможность хоть через тормозной бидон к мощным вычислительным либам интерфейситься. Бидон твой - это такой бэйсик XXI века, с ооп и лямбадми.
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

	56. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+4 +/–
	Сообщение от chinarulezzz (ok), 31-Дек-13, 14:54
	>Бидон твой - это такой бэйсик XXI века, с ооп и лямбадми. как что-то плохое.
	Ответить | Правка | Наверх | Cообщить модератору

	94. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+1 +/–
	Сообщение от Аноним (-), 31-Дек-13, 22:52
	> как что-то плохое. Плохое - это когда некто пытается на себя напялить регалии КВСа, не имея ни малейшего понятия об аэродинамике. Вот большинство погромистов на питоне, которые лезут воротить все это - имеют довольно смутное представление о самых основах. За это я их не люблю. Ссыкотно мне летать с КВСом который аэродинамику не знает.
	Ответить | Правка | Наверх | Cообщить модератору

	96. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–1 +/–
	Сообщение от chinarulezzz (ok), 31-Дек-13, 22:55
	>> как что-то плохое. > Плохое - это когда некто пытается на себя напялить регалии КВСа, не > имея ни малейшего понятия об аэродинамике. Вот большинство погромистов на питоне, > которые лезут воротить все это - имеют довольно смутное представление о > самых основах. За это я их не люблю. Ссыкотно мне летать > с КВСом который аэродинамику не знает. так ты определись, виноват язык в твоих бедах, или программисты, его использующие? Или и то и другое?
	Ответить | Правка | Наверх | Cообщить модератору

	120. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+1 +/–
	Сообщение от Аноним (-), 01-Янв-14, 04:41
	> так ты определись, виноват язык в твоих бедах, или программисты, его использующие? Считается что у питона довольно низкий порог вхождения, как у бэйсика примерно. Поэтому большинство программ на нем обречены быть полным трэшняком. Особенно доставляет в паре с не менее ушибленными авторами языка, постоянно что-то ломающими в плане совместимости. > Или и то и другое? См. выше.
	Ответить | Правка | Наверх | Cообщить модератору

	127. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–2 +/–
	Сообщение от chinarulezzz (ok), 01-Янв-14, 04:56
	так еще и авторы языка виновны? P.S. Зачем ты несмотря на всё это - пользуешься питон-программами? Ведь не поверю что ты мазохист.
	Ответить | Правка | Наверх | Cообщить модератору

	184. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Аноним (-), 03-Янв-14, 05:34
	> так еще и авторы языка виновны? Ну а кто же еще?! Свойства языка закладываются теми кто его писал. > P.S. Зачем ты несмотря на всё это - пользуешься питон-программами? Я как раз ими не пользуюсь теперь. Как раз "если на питоне -> нафиг". Правда просто? :)
	Ответить | Правка | Наверх | Cообщить модератору

	188. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–2 +/–
	Сообщение от chinarulezzz (ok), 03-Янв-14, 06:06
	>> так еще и авторы языка виновны? > Ну а кто же еще?! Свойства языка закладываются теми кто его писал. Значит виноват язык, те кто его использует и те кто его создал. Понятно. >> P.S. Зачем ты несмотря на всё это - пользуешься питон-программами? > Я как раз ими не пользуюсь теперь. Как раз "если на питоне > -> нафиг". Правда просто? :) Нет, не просто. Значит, ты не пользуешься питоном и не страдаешь от программ на этом языке, т.к. не используешь - но тратишь своё время на форуме, информируя всех насколько с питоном всё плохо, с авторами этого языка всё плохо, с теми кто использует этот язык всё плохо, и с программами на этом языке тоже всё плохо. Всё не просто, друг, непросто :-D Эта фиксация ради чего? Может ради идеи какой-то? Зачем тебе это?
	Ответить | Правка | Наверх | Cообщить модератору

	195. "Стратегия параллельного поддержания веток Python 2 и..."	+1 +/–
	Сообщение от arisu (ok), 03-Янв-14, 10:15
	> ради идеи какой-то? Зачем тебе это? если заразу не останавливать, она разрастается.
	Ответить | Правка | К родителю #188 | Наверх | Cообщить модератору

	196. "Стратегия параллельного поддержания веток Python 2 и..."	–1 +/–
	Сообщение от chinarulezzz (ok), 03-Янв-14, 10:23
	>> ради идеи какой-то? Зачем тебе это? > если заразу не останавливать, она разрастается. комплекс спасителя? xD
	Ответить | Правка | К родителю #195 | Наверх | Cообщить модератору

	206. "Стратегия параллельного поддержания веток Python 2 и..."	+1 +/–
	Сообщение от arisu (ok), 03-Янв-14, 12:46
	>>> ради идеи какой-то? Зачем тебе это? >> если заразу не останавливать, она разрастается. > комплекс спасителя? xD не более, чем у человека, который пытается сделать в доме уборку и хочет, чтобы там поменьше сорили.
	Ответить | Правка | К родителю #196 | Наверх | Cообщить модератору

	208. "Стратегия параллельного поддержания веток Python 2 и..."	–1 +/–
	Сообщение от myhand (ok), 03-Янв-14, 14:08
	> не более, чем у человека, который пытается сделать в доме уборку и > хочет, чтобы там поменьше сорили. Не понимаю.  Уборку ты пытаешься сделать в чужом доме, где отродясь не был и о соре имеешь представление только по слухам...   Как это все назвать по-научному?
	Ответить | Правка | К родителю #206 | Наверх | Cообщить модератору

	210. "Стратегия параллельного поддержания веток Python 2 и..."	+/–
	Сообщение от arisu (ok), 03-Янв-14, 14:26
	в своём доме, в своём. если бы грязнули сидели в гетто и не высовывались — другой разговор.
	Ответить | Правка | К родителю #208 | Наверх | Cообщить модератору

	214. "Стратегия параллельного поддержания веток Python 2 и..."	+/–
	Сообщение от myhand (ok), 03-Янв-14, 15:49
	> в своём доме, в своём. Дак в каком-же своем, ежели ты на питоне не пишешь, программы на нем - не используешь.  Читать пробовал: #184, #188? Але? Впрочем, что это я...   Чукча^Warisu, как обычно - не читатель.
	Ответить | Правка | К родителю #210 | Наверх | Cообщить модератору

	279. "Стратегия параллельного поддержания веток Python 2 и..."	+/–
	Сообщение от Аноним (-), 08-Янв-14, 01:47
	> Не понимаю.  Уборку ты пытаешься сделать в чужом доме, Не, извини, моя система - мой дом. И репки к системе - тоже. А вот когда питонисты там глючный трешняк вываливают и приходится отдельно обращать внимание чтобы не наступить в каку - это неприятно, да.
	Ответить | Правка | К родителю #208 | Наверх | Cообщить модератору

	262. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Аноним (-), 08-Янв-14, 00:39
	> Значит виноват язык, те кто его использует и те кто его создал. Как-то так. >> Я как раз ими не пользуюсь теперь. Как раз "если на питоне > Всё не просто, друг, непросто :-D Эта фиксация ради чего? Может > ради идеи какой-то? Зачем тебе это? Идея очень простая: мне не нравится выкапывать нормальные программы среди глючного, тормозного и проблематичного шита, нагенеренного долбанутыми хипстерами. Это усложняет поиск программ и заставляет тратить время на отсев хлама.
	Ответить | Правка | К родителю #188 | Наверх | Cообщить модератору

	267. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–2 +/–
	Сообщение от chinarulezzz (ok), 08-Янв-14, 00:59
	>> Значит виноват язык, те кто его использует и те кто его создал. > Как-то так. >>> Я как раз ими не пользуюсь теперь. Как раз "если на питоне >> Всё не просто, друг, непросто :-D Эта фиксация ради чего? Может >> ради идеи какой-то? Зачем тебе это? > Идея очень простая: мне не нравится выкапывать нормальные программы среди глючного, тормозного > и проблематичного шита, нагенеренного долбанутыми хипстерами. Это усложняет поиск программ > и заставляет тратить время на отсев хлама. ты страдаешь потому что вокруг все виноваты? Как плохо быть тобой. Мне вот, питон не мешает, даже наоборот.
	Ответить | Правка | К родителю #262 | Наверх | Cообщить модератору

	266. "Стратегия параллельного поддержания веток Python 2 и..."	–1 +/–
	Сообщение от arisu (ok), 08-Янв-14, 00:55
	> Значит виноват язык, те кто его использует и те кто его создал. кстати, как-то так, да. низкий порог вхождения, отсутствие налёта «илитарности» (иногда — очень полезная штука), «туториалы», написаные даунами для даунов, etc. — и получаем на выходе вот такой вот ужОс. а с другой стороны — хороший концентратор дебилов. защищает человек гвидобейсик с пеной у рта — дебил с вероятностью, близкой к единице. даже если кажется, что в остальных темах он говорит разумно, дебилизм всё равно проявится. в самый неподходящий момент, и в таком виде, что просто не будешь знать, как на *такое* реагировать.
	Ответить | Правка | К родителю #188 | Наверх | Cообщить модератору

	268. "Стратегия параллельного поддержания веток Python 2 и..."	–1 +/–
	Сообщение от chinarulezzz (ok), 08-Янв-14, 01:01
	> кстати, как-то так, да. низкий порог вхождения, отсутствие налёта «илитарности» > (иногда — очень полезная штука), «туториалы», написаные даунами для даунов, > etc. — и получаем на выходе вот такой вот ужОс. > а с другой стороны — хороший концентратор дебилов. защищает человек гвидобейсик с > пеной у рта — дебил с вероятностью, близкой к единице. даже > если кажется, что в остальных темах он говорит разумно, дебилизм всё > равно проявится. в самый неподходящий момент, и в таком виде, что > просто не будешь знать, как на *такое* реагировать. разумно говоришь. Маловато слов "дебил" и "даун", ящетаю, но в целом аргументы неопровержимые.
	Ответить | Правка | К родителю #266 | Наверх | Cообщить модератору

	270. "Стратегия параллельного поддержания веток Python 2 и..."	+/–
	Сообщение от arisu (ok), 08-Янв-14, 01:11
	> Маловато слов «дебил» и «даун», ящетаю ровно столько, сколько мне нужно было для выражения мысли. > но в целом аргументы неопровержимые. это не «аргументы», это простые практические наблюдения. если в большинстве случаев получается именно так, как я написал — то я буду пользоваться без предварительного подвода огромной теоретической базы. в данном случае ошибка в применении чёрного ящика нефатальна, а профиты — налицо.
	Ответить | Правка | К родителю #268 | Наверх | Cообщить модератору

	271. "Стратегия параллельного поддержания веток Python 2 и..."	–1 +/–
	Сообщение от chinarulezzz (ok), 08-Янв-14, 01:18
	>> Маловато слов «дебил» и «даун», ящетаю > ровно столько, сколько мне нужно было для выражения мысли. краткость - сестра таланта. >> но в целом аргументы неопровержимые. > это не «аргументы», это простые практические наблюдения. если в большинстве > случаев получается именно так, как я написал — то я буду > пользоваться без предварительного подвода огромной теоретической базы. в данном случае > ошибка в применении чёрного ящика нефатальна, а профиты — налицо. зрящий в зримом, говорят некоторые. Но можно посчитать так: питонисты пишут для питонистов софт. Кому не нравится - валите в лес. Выпиливайте этот софт. Не пользуйтесь дистрибуцией, распространяющей подобный софт. Пользуйтесь тем, что нравится вам ;) Заставить питонистов не писать подобный софт вы не можете. Так что терпите. Боритесь. Ломайте систему! xD
	Ответить | Правка | К родителю #270 | Наверх | Cообщить модератору

	281. "Стратегия параллельного поддержания веток Python 2 и..."	+/–
	Сообщение от arisu (ok), 08-Янв-14, 01:58
	да пусть себе пишут. тешатся в своём кругу, хвастаются друг перед другом. но они же считают, что их софт — ого-го, что его можно людям не просто показывать, но и давать пользоваться. а писать на бидоне должно быть так же стыдно, как жрать на мусорке заплесневелые объедки при наличии в доме нормальной еды. нравится жрать с мусорки — на здоровье, но в своём кругу, и ни в коем случае не утверждая, что это нормальное поведение. p.s. чёртов опеннет. я уже сам «тся» и «ться» начинаю писать неправильно.
	Ответить | Правка | К родителю #271 | Наверх | Cообщить модератору

	284. "Стратегия параллельного поддержания веток Python 2 и..."	–2 +/–
	Сообщение от chinarulezzz (ok), 08-Янв-14, 02:14
	> да пусть себе пишут. тешатся в своём кругу, хвастаются друг перед другом. > но они же считают, что их софт — ого-го, что его > можно людям не просто показывать, но и давать пользоваться. какая тебе разница что считают питонщики? Не входи в их круг, и не пользуйся. > а писать > на бидоне должно быть так же стыдно должны тебе? :D >, как жрать на мусорке > заплесневелые объедки при наличии в доме нормальной еды. так не жри. Каждый пусть жрёт что хочет. > нравится жрать с > мусорки — на здоровье, но в своём кругу, и ни в > коем случае не утверждая, что это нормальное поведение. Ты имеешь что-то против еды с мусорки? Не нравится - не ешь. > p.s. чёртов опеннет. я уже сам «тся» и «ться» начинаю писать неправильно. да-да. В этом опеннет виноват xD В дружном экстазе, вплетаясь с питон-хейтерами, мы обвиняем этот мир во всех личных проблемах :D
	Ответить | Правка | К родителю #281 | Наверх | Cообщить модератору

	287. "Стратегия параллельного поддержания веток Python 2 и..."	–1 +/–
	Сообщение от myhand (ok), 08-Янв-14, 02:36
	> какая тебе разница что считают питонщики? Не входи в их круг, и > не пользуйся. Видимо, они видели его (скрытый от широкой апщественности) код (с бле^Wвекторами) и надавали как-то тапком по яй^Wрукам?
	Ответить | Правка | К родителю #284 | Наверх | Cообщить модератору

	290. "Стратегия параллельного поддержания веток Python 2 и..."	–1 +/–
	Сообщение от chinarulezzz (ok), 08-Янв-14, 02:56
	>> какая тебе разница что считают питонщики? Не входи в их круг, и >> не пользуйся. > Видимо, они видели его (скрытый от широкой апщественности) код (с бле^Wвекторами) и > надавали как-то тапком по яй^Wрукам? все здоровые люди кого-то люто-бешено ненавидят, и ораторствуют об объектах своей ненависти по первому попавшемуся случаю ;)
	Ответить | Правка | К родителю #287 | Наверх | Cообщить модератору

	293. "Стратегия параллельного поддержания веток Python 2 и..."	+/–
	Сообщение от myhand (ok), 08-Янв-14, 03:03
	> все здоровые люди кого-то люто-бешено ненавидят, и ораторствуют об объектах своей ненависти > по первому попавшемуся случаю ;) Ну а как тут иначе?  Сидишь, пишешь "алгоритмические засады с векторами" - а тут в этих ваших интернетах какие-то "бидонисты" не правы!
	Ответить | Правка | К родителю #290 | Наверх | Cообщить модератору

	322. "Стратегия параллельного поддержания веток Python 2 и..."	+/–
	Сообщение от Аноним (-), 12-Янв-14, 13:03
	> надавали как-то тапком по яй^Wрукам? Это только у вас ЯП по рукам тапками лупит. Потому что быдлoкодеров надо ставить в стойло. А у бидона это свойство прямо в синтаксис заложено.
	Ответить | Правка | К родителю #287 | Наверх | Cообщить модератору

	336. "Стратегия параллельного поддержания веток Python 2 и..."	+/–
	Сообщение от myhand (ok), 12-Янв-14, 21:38
	>> надавали как-то тапком по яй^Wрукам? > Это только у вас ЯП по рукам тапками лупит. Ох, хорошо бы.  Ежели хорошо будет бить - в качестве дополнительного бонуса получаем невозможность пытуемым писать каку на любых других ЯП (ибо руки потребуются). > Потому что быдлoкодеров > надо ставить в стойло. А у бидона это свойство прямо в > синтаксис заложено. Увы, реальность далека от этого идеала.
	Ответить | Правка | К родителю #322 | Наверх | Cообщить модератору

	288. "Стратегия параллельного поддержания веток Python 2 и..."	+1 +/–
	Сообщение от arisu (ok), 08-Янв-14, 02:38
	это ты с нового года так поглупел, или просто совершил coming-out?
	Ответить | Правка | К родителю #284 | Наверх | Cообщить модератору

	291. "Стратегия параллельного поддержания веток Python 2 и..."	–1 +/–
	Сообщение от chinarulezzz (ok), 08-Янв-14, 02:57
	> это ты с нового года так поглупел, или просто совершил coming-out? всегда таким был. Держи плюсик за прозрение ;)
	Ответить | Правка | К родителю #288 | Наверх | Cообщить модератору

	299. "Стратегия параллельного поддержания веток Python 2 и..."	+/–
	Сообщение от Аноним (-), 08-Янв-14, 08:09
	> кстати, как-то так, да. низкий порог вхождения, отсутствие налёта «илитaрности» ...что не мешает одептам гвидобэйсика гнуть пальцы как будто он есть, что особенно феерично :). > (иногда — очень полезная штука), «туториалы», написаные даyнами для даyнов, Какой ЯП такие и туториалы! > пеной у рта — дeбил с вероятностью, близкой к единице. Еще бывают казуалы. Вот так берешь прогу - вроде хорошая штука. А через годик отваливается и все, досвидания. Надо переписывать половину. А автор давно почил в бозе или тоже не в восторге от нужды все бросить и переписывать.
	Ответить | Правка | К родителю #266 | Наверх | Cообщить модератору

	129. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–4 +/–
	Сообщение от myhand (ok), 01-Янв-14, 14:51
	> Считается что у питона довольно низкий порог вхождения, как у бэйсика примерно. Кем считается, тобой? > Особенно доставляет > в паре с не менее ушибленными авторами языка, постоянно что-то ломающими > в плане совместимости. Приведи пример того, что поломано.  Подчеркиваю, поломано - т.е. не исключено из нового релиза после определенного периода (минимум, один релиз), когда об устаревании удаляемого функционала предупреждали.
	Ответить | Правка | К родителю #120 | Наверх | Cообщить модератору

	185. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+1 +/–
	Сообщение от Аноним (-), 03-Янв-14, 05:37
	> Кем считается, тобой? Не, не мной. Рядом програмеров которых я видел в различных проектах. > Приведи пример того, что поломано.  Подчеркиваю, поломано - т.е. не исключено > из нового релиза после определенного периода (минимум, один релиз), Для меня "поломано" - это когда у меня был некий скрипт и перестал работать. Кого там предупреждали, за сколько релизов и прочая - мне до балды. Это все юления попой которые интересуют только тех кому "питончик, мимими". А я констатирую тот факт что вещи которые ранее работали, работать перестали. И активно трекать развитие языка от очередных долбанашек "ой, а давайте все сломаем и переделаем по уму?" - многовато чести. > когда об устаревании удаляемого функционала предупреждали. Я не нанимался сидеть и караулить с лупой ченжлоги за всякими пи...питонистами. Если скрипт ломается - он ломается. Его переделка - это затраты времени/бабла/сил. Нафиг надо.
	Ответить | Правка | Наверх | Cообщить модератору

	197. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–1 +/–
	Сообщение от chinarulezzz (ok), 03-Янв-14, 10:29
	> многовато чести. Видно что экономишь. P.S. Так будут примеры скриптов, которые ты запуская в 2.1 не мог запустить в 2.7? Вообще, давай сразу от 2.1 до 2.7, любой скрипт который у тебя перестал вдруг работать)))
	Ответить | Правка | Наверх | Cообщить модератору

	265. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Аноним (-), 08-Янв-14, 00:51
	> скрипт который у тебя перестал вдруг работать))) Да гомно вопрос, апдейтер бyбунты уже вторую версию подряд не может запуститься из-за перехода с бидона 2 на бидон 3. Заманали своими перетрясками, честное слово. Просто умрите, фаготы.
	Ответить | Правка | К родителю #197 | Наверх | Cообщить модератору

	269. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–1 +/–
	Сообщение от chinarulezzz (ok), 08-Янв-14, 01:03
	>> скрипт который у тебя перестал вдруг работать))) > Да гомно вопрос, апдейтер бyбунты уже вторую версию подряд не может запуститься > из-за перехода с бидона 2 на бидон 3. Заманали своими перетрясками, > честное слово. Просто умрите, фаготы. У меня запускается. Ладно, виноват питон. Пойду умирать, чо. Вы ж не можете соврать.
	Ответить | Правка | К родителю #265 | Наверх | Cообщить модератору

	300. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Аноним (-), 08-Янв-14, 08:11
	> У меня запускается. А у меня валится с многоэтажным стектрейсом. При том судя по багтрекерам - такая фигня не только у меня... > Ладно, виноват питон. Пойду умирать, чо. Вы ж не можете соврать. Главное гадюку свою не забудьте.
	Ответить | Правка | К родителю #269 | Наверх | Cообщить модератору

	199. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–1 +/–
	Сообщение от myhand (ok), 03-Янв-14, 11:13
	> Для меня "поломано" - это когда у меня был некий скрипт и > перестал работать. Кого там предупреждали, за сколько релизов и прочая - > мне до балды. Ну а всем, умеющим читать - до балды на твои персональные правила. > Я не нанимался сидеть и караулить с лупой ченжлоги за всякими пи...питонистами. Тогда выбери себе полумертвый язык, в котором до бесконечности тянут любой однажды включенный крап.  Закончил ПТУ, выучил по "Язык XYZ для dummies" - и вперед, клепай сайтики до пенсии.  Никаких What's New читать не надо, навыки чтения вообще совершенно опциональные становятся - можешь и вовсе разучиться.  Похоже что уже... > Если скрипт ломается - он ломается. Его переделка - это затраты > времени/бабла/сил. Нафиг надо. Еще один "интырпрайсин", блин.  "Мне платят за фичи."  Наиндусил по чеклисту, получил денюжку и клиент с этим сам будет дальше маяться, так? А мне вот платят - за качественный код и его поддержку.  И ничего не ломается.
	Ответить | Правка | Наверх | Cообщить модератору

	272. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Аноним (-), 08-Янв-14, 01:28
	> Ну а всем, умеющим читать - до балды на твои персональные правила. Как вы лихо то за всех расписываетесь. А вы все 6.5 миллиардов опросили лично? Сомнительно как-то. > Тогда выбери себе полумертвый язык, в котором до бесконечности тянут > любой однажды включенный крап. Зачем? Есть си, если не хватает - плюсы. Для системной автоматизации - шеллскрипты. Их не ломают каждый год, это работает и работает довольно неплохо. Вебня по моим наблюдениям лучше получается у пхпистов. Эти по крайней мере знают свое место и просто работают работу, не корча из себя супергероев. И только питонисты растопыривают пальцы, бьют себя пяткой в грудь, а результат их потуг чаще всего напоминает, простите, блeвoтину. Видимо, синтаксис оптимизированный на загон кодеров пинками в стойло приносит свои плоды - отбираются самые безблагодатные ПТУшники, как вы тут и вещали. > вперед, клепай сайтики до пенсии.  Никаких What's New читать не надо, Я так смотрю, у вас большой опыт в этом деле. Вы явно лучше меня в курсе аудитории таких погромистов. > разучиться.  Похоже что уже... А еще у бидонистов адское ЧСВ. Как-то многовато шума от адептов новоиспеченного бэйсика, которые софт писать толком не умеют. > Еще один "интырпрайсин", блин.  "Мне платят за фичи."  Наиндусил по > чеклисту, получил денюжку и клиент с этим сам будет дальше маяться, так? А если надо активно майнтайнить вообще каждый клочок кода - все придет к тому что будет убиваться вагон времени на майнтенанс. > А мне вот платят - за качественный код и его поддержку. Это с точки зрения клиента назвается "залет". Сперва заплатить полудурошному быдлoкодеру, а потом еще и доплачивать за фиксинг его косяков и бзики тех кто ему инструментарий делал. Отличная причина не нанимать питониста - потом много затрат будет, на ровном месте. "Потому что гвидо и его шайке раздолбаев шлея под хвост попала".    > И ничего не ломается. Если бы ничего не ломалось - поддержка не требовалась бы. С уважением, Капитан Очевидность.
	Ответить | Правка | К родителю #199 | Наверх | Cообщить модератору

	283. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 08-Янв-14, 02:12
	>> Ну а всем, умеющим читать - до балды на твои персональные правила. > Как вы лихо то за всех расписываетесь. А вы все 6.5 миллиардов > опросили лично? Сомнительно как-то. А зачем мне столько опрашивать?  Столько разработчиков не наберется, если даже учесть программистов на всех языках, вместе взятых.  Или даже просто умеющих читать. Интересует пересечение множеств умеющих читать и использующих питон. >> Тогда выбери себе полумертвый язык, в котором до бесконечности тянут >> любой однажды включенный крап. > Зачем? Есть си, если не хватает - плюсы. Не надоело корявыми ручонками переизобретать сборку мусора? > Для системной автоматизации - > шеллскрипты. Их не ломают каждый год, это работает и работает довольно неплохо. Шеллскрипты - куцый язык (ежели POSIX-совместимые).  А все что сверх POSIX, ключи утилит и проч. - ломают еще почище чем раз в год. > И только питонисты растопыривают пальцы, бьют себя пяткой в грудь ... Ты явно воюешь с каким-то жупелом в собственном воображении. >> вперед, клепай сайтики до пенсии.  Никаких What's New читать не надо, > Я так смотрю, у вас большой опыт в этом деле. Видимо, угадал твою "профессиональную" область. >> Еще один "интырпрайсин", блин.  "Мне платят за фичи."  Наиндусил по >> чеклисту, получил денюжку и клиент с этим сам будет дальше маяться, так? > А если надо активно майнтайнить вообще каждый клочок кода - все придет > к тому что будет убиваться вагон времени на майнтенанс. А ты пиши по-человечески - не будет убиваться. >> И ничего не ломается. > Если бы ничего не ломалось - поддержка не требовалась бы. API ломают везде и всюду - не надо корчить рожу, что это придумали разработчики питона.  И старый хлам из дистрибутивов выпиливают.  Это только одна причина, почему твой продукт у пользователя может поломаться. Вторая причина необходимости поддержки (ясная всем, кроме индусов вроде тебя) - обычные баги.  Только ты в этом мире считаешь, что пишешь эксклюзивно безбажный софт.  А на самом деле, верифицированные программы - можно пересчитать по пальцам.
	Ответить | Правка | К родителю #272 | Наверх | Cообщить модератору

	301. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Аноним (-), 08-Янв-14, 08:50
	> А зачем мне столько опрашивать? Ну вы сказали - "всем". Вот я интересуюсь - как померяно что и правда "всем"? :) > умеющих читать. У меня есть сомнения что вы опрашивали именно ВСЕХ умеющих читать. > Интересует пересечение множеств умеющих читать и использующих питон. О, уже интереснее. Путем небольшого уточнения множество сдувается в 100500 раз. Но даже в этом случае есть сомнения что ВСЕ ведут себя указанным образом. Все-равно попахивает махровым на...ловом и подтасовками. > Не надоело корявыми ручонками переизобретать сборку мусора? Меня анноят автоматические подтиралки зада, которые лучше меня знают когда мне требуется ж... подтереть. К тому же в половине случаев они используют наждачную бумагу вместо туалетной. Прикольно читать советы вида "как все-таки убедить этот мега-агрегат использовать туалетную бумагу вместо наждачной". > Шеллскрипты - куцый язык (ежели POSIX-совместимые). Вполне достаточно для glue-кода между утилитами и системной автоматизации, имхо. >  А все что сверх POSIX, ключи утилит и проч. - ломают еще почище > чем раз в год. Весьма зависит от утилит и их авторов. Кроме того, при использовании питона вместо баша проблемы никуда не деваются. Редкий питонист рискнет здоровьем написать целиком на питоне какой-нибудь ffmpeg. Тем более что если все будет на питоне - Солнце погаснет раньше чем питоновый ушлeпок закончит кодирование в другой формат. > Ты явно воюешь с каким-то жупелом в собственном воображении. Да ладно, в этом треде образчиков надергать можно. Вот вы, например. Вашим софтом я не стал бы пользоваться даже если за это доплатят - вы уже сказали достаточно, мне все ясно с вашей квалификацией и отношением к делу. Вы, таки, разыскиваете лохов и потом они еще и залетают на доплаты за поддержку вашего крапа. > Видимо, угадал твою "профессиональную" область. Нене, это только вы спалились, блеснув подозрительно хорошим знанием предметной области. Выпускника кулинарного техникума сразу видно. Странно правда что там питону обучали, а не вьюжлвасику из экселя или 1С какому-нибудь. Впрочем, не больно какая громадная разница. > А ты пиши по-человечески - не будет убиваться. Так у _меня_ и не убивается. Но это не мешает видеть ДЛБ с питоном и воплями "ой, опять не работает". > API ломают везде и всюду - не надо корчить рожу, что это > придумали разработчики питона. Не знаю, в сях например апи стандартной либы, POSIX и прочая как-то вот дожили до наших дней, в виде когда программа конца 80-х прошлого века собирается и работает, если не юзает какой-то системной специфики конкретной ОС/проца/etc. Древние шеллскрипты - до сих пор работают, не хуже чем раньше. А питонный скрипт 5-летней давности с вероятностью процентов 70 вообще не заработает вот так сразу без плясок с бубном или переписывания. > Это только одна причина, почему твой продукт у пользователя может поломаться. Вы в такие моменты забываете уточнить только 1 вещь: что такой продукт - это продукт жизнедеятельности. Ах, не только фундамент может развалиться но еще и стены могут рассыпаться? Или даже кирпичи рассыпаются в пыль? Сами и живите в таком сарае. А мне не нравятся подобные свойства софта. > Вторая причина необходимости поддержки (ясная всем, кроме индусов вроде тебя) У меня нет родственников в индии, обломайтесь. > - обычные баги.  Только ты в этом мире считаешь, что пишешь эксклюзивно > безбажный софт. Я так не считаю. Но вижу что софт на питоне - наиболее проблемный и глючный, благодаря возведению рапидчины в культ, непомерному ЧСВ програмеров и ориентации ЯП на вполне конкретную ЦА, которая настолько лыка не вяжет, так что даже форматировать код по человечески может лишь путем волшебных пинков. > А на самом деле, верифицированные программы - можно пересчитать по пальцам. Что иронично, какой-нить djbdns писан вообще на сях и его что-то так и не сломали, потому что багов мизер. Зато moinmoin на питоне - очень даже. Видимо, кивание на то что вумный рантайм подумает за программера - не очень то работает, да? А постоянное автоподтирание зада и загон пинками в стойло - растит слабоумных нерюхов, которые вообще не знают нихрена, но какой-то гомнокод на-гора таки выдают.
	Ответить | Правка | К родителю #283 | Наверх | Cообщить модератору

	63. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 31-Дек-13, 15:37
	> Они же в большей части нубы и дубы в разработке. "Они" (http://scipy.org/) - делают, пожалуй, самый качественный и нетривиальный код на Python и вокруг него. А ты думал, джанги? > а задача оптимизации CPython несколько легче. А добавь там оптимизацию хвостовой рекурсии.  Когда патча ждать?
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

	157. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+1 +/–
	Сообщение от Michael Shigorin (ok), 02-Янв-14, 13:29
	> А добавь там оптимизацию хвостовой рекурсии.  Когда патча ждать? Ну кто ж на рептилиях занимается хвостовой рекурсией -- для этого есть куда более подходящие языки (и лямбду из таких точно никто выбрасывать не задумается, в отличие от структуральнейшего).
	Ответить | Правка | Наверх | Cообщить модератору

	168. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 02-Янв-14, 16:00
	>> А добавь там оптимизацию хвостовой рекурсии.  Когда патча ждать? > Ну кто ж на рептилиях занимается хвостовой рекурсией А почему, собственно, нет?  Много всяческой функциональщины уже давно включено.
	Ответить | Правка | Наверх | Cообщить модератору

	183. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+1 +/–
	Сообщение от Michael Shigorin (ok), 03-Янв-14, 02:26
	>>> А добавь там оптимизацию хвостовой рекурсии.  Когда патча ждать? >> Ну кто ж на рептилиях занимается хвостовой рекурсией > А почему, собственно, нет?  Много всяческой функциональщины уже давно включено. Потому что: - дамоклов меч в виде непонимания Гвидо; - проблемы на ровном месте, с которых этот субтред и начался. Потихоньку пробую на зуб picolisp, когда время есть...
	Ответить | Правка | Наверх | Cообщить модератору

	200. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 03-Янв-14, 11:18
	>>>> А добавь там оптимизацию хвостовой рекурсии.  Когда патча ждать? >>> Ну кто ж на рептилиях занимается хвостовой рекурсией >> А почему, собственно, нет?  Много всяческой функциональщины уже давно включено. > Потому что: > - дамоклов меч в виде непонимания Гвидо; Мне кажется, Гвидо вполне понимает проблемы включения такой штуки в CPython.  Главный его аргумент: "TRE is incompatible with nice stack traces". http://neopythonic.blogspot.ru/2009/04/tail-recursion-elimin... > - проблемы на ровном месте, с которых этот субтред и начался. Это которые, напомните?
	Ответить | Правка | Наверх | Cообщить модератору

	205. "Стратегия параллельного поддержания веток Python 2 и..."	–1 +/–
	Сообщение от arisu (ok), 03-Янв-14, 12:44
	> Мне кажется, Гвидо вполне понимает проблемы включения такой штуки в CPython. угу. в виде «а мне оно не надо и я не понимаю, зачем оно вообще кому-то надо». > Главный его аргумент: «TRE is incompatible with nice stack traces». не главный, а первый. и сразу же дурацкий: сделать флажок «отладочный запуск», где TCO отключено — не судьба? end user всё равно отлаживать не будет, а разработчик — пусть себе. inb4: нет, глубоко рекурсивные алгоритмы в таком флажке нуждаться не будут, потому что глубоко рекурсивные алгоритмы выдают что угодно, только не nice stack trace. ну, и дальше у него продолжается «я не понимаю, зачем это надо и как это использовать, поэтому оно не надо».
	Ответить | Правка | Наверх | Cообщить модератору

	209. "Стратегия параллельного поддержания веток Python 2 и..."	–1 +/–
	Сообщение от myhand (ok), 03-Янв-14, 14:17
	>> Главный его аргумент: «TRE is incompatible with nice stack traces». > не главный, а первый. и сразу же дурацкий: сделать флажок «отладочный запуск», > где TCO отключено — не судьба? Ох, дурилка...  Отлаживать будешь реальные программы - или сферических коней? TRE не просто оптимизация.  Если ты пишешь код, который зависит от нее - с TRE=off этот код может попросту не заработать.  Так что ты обязан включить это по-умолчанию, ежели такой стиль программирования языком благословляется.  И, таким образом, автоматически теряешь "nice stack traces" по-умолчанию же.  Во *всех* программах, не только использующих глубоко рекурсивные алгоритмы.  Гвидо справедливо считает такой вариант неприемлемым. > ну, и дальше у него продолжается «я не понимаю, зачем это надо > и как это использовать, поэтому оно не надо». Дальше более хвилософские пункты, но никак не "я не понимаю зачем это надо".
	Ответить | Правка | Наверх | Cообщить модератору

	212. "Стратегия параллельного поддержания веток Python 2 и..."	+1 +/–
	Сообщение от arisu (ok), 03-Янв-14, 15:33
	> Ох, дурилка… не беседуй с зеркалом. > TRE не просто оптимизация.  Если ты пишешь код, который зависит от > нее — с TRE=off > этот код может попросту не заработать. пример в студию. TCO *не меняет* семантику кода. прикинь. ну, и про то, что end user ничего отлаживать не будет и у него завсегда TCO включено — ты весело проигнорировал, потому что оно мешает громить воображаемое чучелко. > Гвидо справедливо считает такой вариант неприемлемым. опоссум, как я уже сказал, просто не понимает, что такое TCO, зачем оно надо и как применяется. что характерно — его защитники тоже, как видим.
	Ответить | Правка | Наверх | Cообщить модератору

	213. "Стратегия параллельного поддержания веток Python 2 и..."	+/–
	Сообщение от myhand (ok), 03-Янв-14, 15:45
	>> TRE не просто оптимизация.  Если ты пишешь код, который зависит от >> нее — с TRE=off >> этот код может попросту не заработать. > пример в студию. Ох, дурилка, лови: def fac(n, acc=1):     if n <= 0:         return acc     return fac(n - 1, n*acc) У меня, например, уже fac(1000) отваливается с maximum recursion depth exceeded.  Понял?   > TCO *не меняет* семантику кода. прикинь. Я утверждал обратное?  Нет. > ну, и про то, что end user ничего отлаживать не будет и > у него завсегда TCO включено — ты весело проигнорировал Отлаживать будет не end user, а я.   И от end user'а для этого мне "nice stack traces" - очень даже не помешают. >> Гвидо справедливо считает такой вариант неприемлемым. > опоссум, как я уже сказал, просто не понимает, что такое TCO, зачем > оно надо и как применяется. Ну-ну, "все идиоты, прям как я".  Хош - верь в это, мне все равно.
	Ответить | Правка | Наверх | Cообщить модератору

	273. "Стратегия параллельного поддержания веток Python 2 и..."	–1 +/–
	Сообщение от Аноним (-), 08-Янв-14, 01:32
	> У меня, например, уже fac(1000) отваливается с maximum > recursion depth exceeded.  Понял? А ты думал что тебе позволят бесконечно жрать память под стэк и она никогда не закончится? И что в рантайме, ОС и прочая на это будут спокойно смотреть вплоть до момента когда в системе не останется ни бита свободной памяти и все умрет жестокой смертью, максимально глобально и масштабно? Эти гоблины-питонисты такие предсказуемые... :)
	Ответить | Правка | К родителю #213 | Наверх | Cообщить модератору

	278. "Стратегия параллельного поддержания веток Python 2 и..."	+1 +/–
	Сообщение от myhand (ok), 08-Янв-14, 01:47
	>> У меня, например, уже fac(1000) отваливается с maximum >> recursion depth exceeded.  Понял? > А ты думал что тебе позволят бесконечно жрать память под стэк и > она никогда не закончится? Значит, не понял... Может тебя, дурилка, это удивит, но есть масса ЯП, в т.ч. скриптовых, где нет такого искусственного ограничения на глубину рекурсии.  Собственно, любой функциональный ЯП. Что не отменяет физических ограничений и ограничений, налагаемых операционной системой на исполняемый код (e.g. man ulimit). > Эти гоблины-питонисты такие предсказуемые... :) В общем, прежде чем взрослых дядей учить и лезть в дискуссию со своими "индеями" - разберись о чем вообще идет речь.  Впрочем, вероятно это пожелание - впустую...
	Ответить | Правка | К родителю #273 | Наверх | Cообщить модератору

	282. "Стратегия параллельного поддержания веток Python 2 и..."	–1 +/–
	Сообщение от Аноним (-), 08-Янв-14, 02:04
	> где нет такого искусственного ограничения на глубину рекурсии. В общем случае даже нативный код довольно быстро трапнется по "искусственному" ограничению на размер стэка, весьма далекому от полного размера памяти системы. Потому что система многозадачная и многопользовательская, а такое поведение как правило результат "runaway". Не должна программа в общем случае уходить в неограниченную рекурсию. Рекурсия с глубиной более 1000 - уже неплохая заявка на победу в Специальной Олимпиаде. > Что не отменяет физических ограничений и ограничений, налагаемых операционной системой > на исполняемый код (e.g. man ulimit). Да, расскажи мне про управление памятью и физические лимиты, бидонист. Хочу посмотреть сколько раз ты в процессе облажаешься. > вероятно это пожелание - впустую... Конечно. Ведь ты не взрослый дядя судя по твоему детскому поведению и синдрому утенка.
	Ответить | Правка | К родителю #278 | Наверх | Cообщить модератору

	286. "Стратегия параллельного поддержания веток Python 2 и..."	+1 +/–
	Сообщение от myhand (ok), 08-Янв-14, 02:26
	> Не должна программа в общем случае уходить в неограниченную рекурсию. Она и не уходит.  Твой КО. > Рекурсия с глубиной более 1000 - уже неплохая заявка на победу > в Специальной Олимпиаде. Что такого страшного в вычислении факториала 1000?  (См. пример. #213) Тот же код - работает в соседнем интерпретаторе схемы.  Самый обычный, букварный, пример tail-recursive функции. >> Что не отменяет физических ограничений и ограничений, налагаемых операционной системой >> на исполняемый код (e.g. man ulimit). > Да, расскажи мне про управление памятью и физические лимиты Да не поймешь ты ничего, дурилка :)  Думаешь это мне одному тут понятно? >> вероятно это пожелание - впустую... > Конечно. Я и не сомневался.
	Ответить | Правка | К родителю #282 | Наверх | Cообщить модератору

	302. "Стратегия параллельного поддержания веток Python 2 и..."	+/–
	Сообщение от Аноним (-), 08-Янв-14, 09:23
	> Она и не уходит.  Твой КО. Тогда с фига ли жалобы? Такой алгоритм обречен налетать на грабли при достаточно большой глубине рекурсии. > Что такого страшного в вычислении факториала 1000?  (См. пример. #213) Того что завтра кто-нибудь совершенно без задней мысли попробует дать на вход N побольше и будет немало удивлен результатам. > Тот же код - работает в соседнем интерпретаторе схемы.   А вы при вычислении факториала N побольше на вход подайте :). > Самый обычный, букварный, пример tail-recursive функции. Капитан Очевидность информирует что рекурсивные функции могут жрать прорву памяти, да еще в зависимости от входных параметров. При том далеко не самым очевидным образом. Что делает их достаточно стремной штукой в целом. То что бидонисты дополнительно зарубили своим скрипткидям это дело - вполне в духе питона. Если уж пинками код форматировать загоняют - давать неограниченно делать потенциально опасные операции и вовсе не айс. > Да не поймешь ты ничего, дурилка :)  Думаешь это мне одному тут понятно? Дурилкой тут, имхо, выступает кто-то другой. А я так, тролололю по мелочи.
	Ответить | Правка | К родителю #286 | Наверх | Cообщить модератору

	308. "Стратегия параллельного поддержания веток Python 2 и..."	–1 +/–
	Сообщение от myhand (ok), 08-Янв-14, 12:32
	>> Она и не уходит.  Твой КО. > Тогда с фига ли жалобы? Такой алгоритм обречен налетать на грабли при > достаточно большой глубине рекурсии. Любой алгоритм умеет "налетать на грабли" в виде физических ограничений.  Память закончится, результата работы будешь ждать пока Луна не улетит и т.п. Речь шла совсем о другом. >> Тот же код - работает в соседнем интерпретаторе схемы. > А вы при вычислении факториала N побольше на вход подайте :). Я констатирую что ты не понял о чем вообще дяди беседовали. >> Самый обычный, букварный, пример tail-recursive функции. > Капитан Очевидность информирует что рекурсивные функции > могут жрать прорву памяти Школу закончи, а потом уже пробуй КО из себя изображать.
	Ответить | Правка | К родителю #302 | Наверх | Cообщить модератору

	323. "Стратегия параллельного поддержания веток Python 2 и..."	+/–
	Сообщение от Аноним (-), 12-Янв-14, 13:12
	> Любой алгоритм умеет "налетать на грабли" в виде физических ограничений. Раз вы так настаиваете - поясните, пожалуйств, что в вашем понимании является "физическими ограничениями" в данном случае. И заодно расскажите почему большинство рантаймов пристрелит программу задолго до того как на хранение данных в стеке израсходуется хотя-бы половина системной оперативки. >  Память закончится, результата работы будешь ждать пока Луна не улетит и т.п. Ага, ващи знания об основах работы компьютеров - на уровне папаса смотрящего на микроволновку. Так и запишем. > Речь шла совсем о другом. Если посмотреть на практические реализации - обычно рекурсию пристреливают намного раньше чем на это уйдет хотя-бы половина памяти имеющейся в системе. Наверное бывают какие-то сильно особенные случаи, но большинство рантаймов как-то по дефолту волком смотрит на попытки жрать тонны оперативки весьма косвенными и неочевидными методами. > Школу закончи, а потом уже пробуй КО из себя изображать. Это у вас пробелы в знаниях. Вы вашим мемеканиям про физические лимиты ща поставите себя в очень интересную позу.
	Ответить | Правка | К родителю #308 | Наверх | Cообщить модератору

	222. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+1 +/–
	Сообщение от netch (ok), 07-Янв-14, 13:36
	>>>>> А добавь там оптимизацию хвостовой рекурсии.  Когда патча ждать? > Мне кажется, Гвидо вполне понимает проблемы включения такой штуки в CPython.   > Главный его аргумент: "TRE is incompatible with nice stack traces". > http://neopythonic.blogspot.ru/2009/04/tail-recursion-elimin... И чем же он мешает? Просто в отладочном режиме в метаданных фрейма надо хранить ещё два параметра - * имя функции, которая вызывалась исходно (или, альтернативно, функцию, на которую перешли; главное, чтобы в итоге их было две) * количество TRE, применённых в данном фрейме. BTW после работы с Erlang, в котором на это чихали с колокольни и всегда видна только последняя функция в цепочке TRE, я думаю, что это не так и страшно. Очень редко получаются ситуации, когда действительно нельзя найти анализом, что же это было. А если явно добавить атрибут разрешения хвостовой рекурсии, а по умолчанию её не делать - получится вообще отлично - кто разрешил себе наступать на грабли, только тот и наступит.
	Ответить | Правка | К родителю #200 | Наверх | Cообщить модератору

	230. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–1 +/–
	Сообщение от myhand (ok), 07-Янв-14, 14:55
	>>>>>> А добавь там оптимизацию хвостовой рекурсии.  Когда патча ждать? >> Мне кажется, Гвидо вполне понимает проблемы включения такой штуки в CPython. >> Главный его аргумент: "TRE is incompatible with nice stack traces". >> http://neopythonic.blogspot.ru/2009/04/tail-recursion-elimin... > И чем же он мешает? Просто в отладочном режиме в метаданных фрейма > надо хранить ещё два параметра - Начнем с того, что у питона *нет* отладочного режима. Я, собственно, не говорю что решение вообще невозможно - но для CPython никто пока ничего так и не предложил. > А если явно добавить атрибут разрешения хвостовой рекурсии, а по умолчанию её > не делать - получится вообще отлично - кто разрешил себе наступать > на грабли, только тот и наступит. Про такое "решение" я уже писал, см. где-то отсюда: #209
	Ответить | Правка | Наверх | Cообщить модератору

	235. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от netch (ok), 07-Янв-14, 19:21
	>>>>>>> А добавь там оптимизацию хвостовой рекурсии.  Когда патча ждать? >>> Мне кажется, Гвидо вполне понимает проблемы включения такой штуки в CPython. >>> Главный его аргумент: "TRE is incompatible with nice stack traces". >>> http://neopythonic.blogspot.ru/2009/04/tail-recursion-elimin... >> И чем же он мешает? Просто в отладочном режиме в метаданных фрейма >> надо хранить ещё два параметра - > Начнем с того, что у питона *нет* отладочного режима. Можно принять за оный запуск без ключика -O. Но вообще-то жаль, что и в этом направлении тоже нет подвижек. >> А если явно добавить атрибут разрешения хвостовой рекурсии, а по умолчанию её >> не делать - получится вообще отлично - кто разрешил себе наступать >> на грабли, только тот и наступит. > Про такое "решение" я уже писал, см. где-то отсюда: #209 Прочитал. Не вижу там никаких возражений против моего предложения.
	Ответить | Правка | Наверх | Cообщить модератору

	248. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Я (??), 07-Янв-14, 23:01
	> Начнем с того, что у питона *нет* отладочного режима. > Я, собственно, не говорю что решение вообще невозможно - но для CPython > никто пока ничего так и не предложил. Это как? А pdb на что, а в PyCharm debug это для кого? https://www.google.ru/search?client=safari&rls=en&q=python+d...
	Ответить | Правка | К родителю #230 | Наверх | Cообщить модератору

	294. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 08-Янв-14, 03:13
	>> Начнем с того, что у питона *нет* отладочного режима. > Это как? А pdb на что А pdb - это отладчик.
	Ответить | Правка | Наверх | Cообщить модератору

	39. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–3 +/–
	Сообщение от Аноним (-), 31-Дек-13, 13:24
	> сделать только представители научной части пользователей Python. Они в программировании лыка не вяжут и используют питон лишь потому что это такой бэйсик современный, который освоить может даже кухарка кой-как.
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	62. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+6 +/–
	Сообщение от mimimi (?), 31-Дек-13, 15:34
	ждём.   $ python   Python 3.3.3 (default, Nov 26 2013, 13:33:18)   [GCC 4.8.2] on linux   Type "help", "copyright", "credits" or "license" for more information.   >>> import timeit   >>> timeit.repeat('for i in range(100): i**2', repeat=3, number=100000)   [4.451958370991633, 4.446133581004688, 4.4439384159923065]   >>> timeit.repeat('for i in range(100): pow(i,2)', repeat=3, number=100000)   [5.343420933000743, 5.341413081012433, 5.3455389970040414]   >>> timeit.repeat('for i in range(100): i*i', repeat=3, number=100000)   [0.8348780410015024, 0.8323301089985762, 0.8313860019989079]   $ python2   Python 2.7.6 (default, Nov 26 2013, 12:52:49)   [GCC 4.8.2] on linux2   Type "help", "copyright", "credits" or "license" for more information.   >>> import timeit   >>> timeit.repeat('for i in range(100): i**2', repeat=3, number=100000)   [0.9710979461669922, 0.9630119800567627, 0.9619340896606445]   >>> timeit.repeat('for i in range(100): pow(i,2)', repeat=3, number=100000)   [1.7429649829864502, 1.7306430339813232, 1.729590892791748]   >>> timeit.repeat('for i in range(100): i*i', repeat=3, number=100000)   [0.6579899787902832, 0.6526930332183838, 0.6540830135345459]   $ python -m timeit '"-".join(str(n) for n in range(100))'; python -m timeit '"-".join([str(n) for n in range(100)])'; python -m timeit '"-".join(map(str, range(100)))'   10000 loops, best of 3: 49.4 usec per loop   10000 loops, best of 3: 40.6 usec per loop   10000 loops, best of 3: 32.8 usec per loop   $ python2 -m timeit '"-".join(str(n) for n in range(100))'; python2 -m timeit '"-".join([str(n) for n in range(100)])'; python2 -m timeit '"-".join(map(str, range(100)))'   10000 loops, best of 3: 30.2 usec per loop   10000 loops, best of 3: 25 usec per loop   10000 loops, best of 3: 19.4 usec per loop   $ uname -rom   3.12.6-1-ARCH x86_64 GNU/Linux
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	13. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Аноним (-), 31-Дек-13, 11:30
	> Поддержка последней версии python2.7 закончится через год, рискуешь остаться с устаревшими знаниями. Это только поддержка оригинальными разработчиками. А вот дистрибутивщики (Debian, RHEL) будут тащить второй питон еще лет пять.
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	14. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+1 +/–
	Сообщение от Аноним (-), 31-Дек-13, 11:32
	Хочется надеяться на десять.
	Ответить | Правка | Наверх | Cообщить модератору

	18. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+7 +/–
	Сообщение от web (?), 31-Дек-13, 11:46
	> Это только поддержка оригинальными разработчиками. А вот дистрибутивщики (Debian, RHEL) > будут тащить второй питон еще лет пять. для RHEL 6 есть RH Software Collections: http://developerblog.redhat.com/2013/09/12/rhscl1-ga/ у дебиан более короткий цикл поддержки, плюс возможность обновления пакетов через testing-репозиторий, который стабильней многих серверных Убунт.
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	41. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Аноним (-), 31-Дек-13, 13:30
	> который стабильней многих серверных Убунт. Я и видел - как grub в тестинге выпал в unbootable после перезагрузки в неудачный момент. В убунтах такого п-ца как небутабельная машина все-таки не встречается. А testing на то и testing что могут все сломать без предупреждения. Хинт: в серверной убунте никто не меняет версии софта на ходу, между релизами. А вот в тестинге - могут.
	Ответить | Правка | Наверх | Cообщить модератору

	112. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–1 +/–
	Сообщение от Аноним (-), 01-Янв-14, 01:54
	О! cпасибо за анекдот под йолочку! %-)
	Ответить | Правка | Наверх | Cообщить модератору

	122. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Аноним (-), 01-Янв-14, 04:46
	> О! cпасибо за анекдот под йолочку! %-) А там как-то так изредка случается что grub одной версии, а модули - другой. Видел несколько интересных факапов такого плана, выглядит мило: grub не может вгрузить ни 1 модуль. Все, занавес: система не бутабельна и сама из себя не чинится.
	Ответить | Правка | Наверх | Cообщить модератору

	138. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+1 +/–
	Сообщение от XoRe (ok), 01-Янв-14, 16:55
	> В убунтах такого п-ца как небутабельная машина все-таки не встречается. Ви что, не помните момент перехода с grub на grub2 ?
	Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

	186. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Аноним (-), 03-Янв-14, 05:41
	> Ви что, не помните момент перехода с grub на grub2 ? У дебианщиков умудряются сфакапить даже grub2 между его разными версиями каким-то чудом. Редко, но метко. В убунтах такой факап если и случится то только при апгрейде релиза на релиз. А в дебиан-тестинге такой прикол может в принципе произойти в любой момент, что как-то не айс совсем. Прикиньте - вам надо срочно что-то сделать, а система вам и говорит - "отдыхайте, грузиться сегодня не будем".
	Ответить | Правка | Наверх | Cообщить модератору

	198. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Andrey Mitrofanov (?), 03-Янв-14, 10:30
	> совсем. Прикиньте - вам надо срочно что-то сделать, а система вам > и говорит - "отдыхайте, грузиться сегодня не будем". Ага, на RHEL6 на неделе забегал по граблям.
	Ответить | Правка | Наверх | Cообщить модератору

	276. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–1 +/–
	Сообщение от Аноним (-), 08-Янв-14, 01:39
	> Ага, на RHEL6 на неделе забегал по граблям. Ну я рхелы не лю, у них пакетный менеджер гадский очень, в том числе и благодаря сабжевому ЯП. Поэтому меня их грабли меньше напрягают. А вот приколы в дебиан тестинге несколько раз встречались. Так что лично для себя я все-таки предпочитаю комьюнити-билды убунты типа хубунтов.
	Ответить | Правка | Наверх | Cообщить модератору

	218. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Crazy Alex (ok), 04-Янв-14, 02:10
	как бы тестинг ровно это и предполагает - что истема МОЖЕТ стать нерабочей. Я когда-то вообще на одновременно поломанные apt и xorg попал. Ну так знал же, что ставлю, поэтому не возмущался, а спокойно скачал руками старые версии apt сотоварищи, откатился, подождал пару дней, пока починят.
	Ответить | Правка | К родителю #186 | Наверх | Cообщить модератору

	289. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от PnD (ok), 08-Янв-14, 02:51
	Дебиано-убунты начинаются с dash, однако. Оно ломает совместимость с shell, так что "кросс-платформенные" скрипты с "#/bin/sh" в заголовке внезапно вылетают с ошибкой синтаксиса, при том что работают как часы с (bash|ksh|t?csh).   Что лично для меня выглядит чётким клеймом пионер-строя, наряду с 3-мя (на данный момент) версиями ubuntu 12.04 "lts" (ага) и непринуждённой поломкой конфига компиляемого под debian exim (было такое в районе 4.70 - crl из файла внезапно превратился в каталог, редхатовцы "сюрприз" вовремя заметили и выпиилили).
	Ответить | Правка | К родителю #186 | Наверх | Cообщить модератору

	292. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 08-Янв-14, 02:59
	>   Дебиано-убунты начинаются с dash, однако. Оно ломает совместимость с shell, Ох, дурилко.  Дебиано-бубунтовый dash и есть этот самый shell, который в POSIX стандарте прописан... > так что "кросс-платформенные" скрипты с "#/bin/sh" в заголовке внезапно вылетают с > ошибкой синтаксиса, при том что работают как часы с (bash|ksh|t?csh). Вот такие вот они кроссплатформенные. Как ты думаешь, ежели ты будешь в своем приплюснутом чуде активно использовать всяки  VC++ расширения - gcc этот shit соберет?  То-то.  Тут абсолютно то же самое.  Пишешь скрипт в расчете на стандарт - он будет переносимым. Так что "#/bin/sh" в начале ваших "кросс-платформенных скриптов" на bash - просто баг.  Так-то вот. >  Что лично для меня выглядит чётким клеймом пионер-строя Игнорирование стандартов - вот реальный признак "пионерстроя".  А уж тем более - полное их незнание...
	Ответить | Правка | Наверх | Cообщить модератору

	298. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Michael Shigorin (ok), 08-Янв-14, 04:34
	> Ох, дурилко.  Дебиано-бубунтовый dash и есть этот самый shell, который в > POSIX стандарте прописан... Хватит врать уже, а? http://www.opennet.me/openforum/vsluhforumID3/63734.html#28 > Игнорирование стандартов - вот реальный признак "пионерстроя".  А уж тем более > - полное их незнание... И тем более попытки подмены реализации стандарта местечковым поделием с фанатическим воем.
	Ответить | Правка | Наверх | Cообщить модератору

	304. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+1 +/–
	Сообщение от myhand (ok), 08-Янв-14, 11:56
	>> Ох, дурилко.  Дебиано-бубунтовый dash и есть этот самый shell, который в >> POSIX стандарте прописан... > Хватит врать уже, а? > http://www.opennet.me/openforum/vsluhforumID3/63734.html#28 Я не вру, Михаил.  Баги везде есть и они исправляются: http://www.opennet.me/openforum/vsluhforumID3/93349.html#374 >> Игнорирование стандартов - вот реальный признак "пионерстроя".  А уж тем более >> - полное их незнание... > И тем более попытки подмены реализации стандарта местечковым поделием с фанатическим воем. И тем более - непрофессиональные заявления о подменах стандартов на основе информации о багах пятилетней давности...
	Ответить | Правка | Наверх | Cообщить модератору

	314. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Michael Shigorin (ok), 08-Янв-14, 17:49
	>>> Дебиано-бубунтовый dash и есть этот самый shell, >>> который в POSIX стандарте прописан... >> Хватит врать уже, а? > Я не вру, Михаил.  Баги везде есть и они исправляются: Спасибо, порадовали; простите.  Чтоб окончательно утихомириться -- покажете dash в стандарте? :)
	Ответить | Правка | Наверх | Cообщить модератору

	315. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 08-Янв-14, 18:26
	> Чтоб окончательно утихомириться -- покажете dash в стандарте? В смысле?  POSIX shell - есть в стандарте Debian (policy).  А dash - именно минимальный shell для нужд Debian.  "Only features designated by POSIX, plus a few Berkeley extensions, are being incorporated into this shell." (c) man.  "few extensions" указаны в policy.  Что сверх этого - баг.
	Ответить | Правка | Наверх | Cообщить модератору

	140. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+1 +/–
	Сообщение от Аноним (-), 01-Янв-14, 19:31
	На серверы нельзя ставить тестинг. Обновления безопасности в него прилетают позже, чем в стейбл.
	Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

	31. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от бедный буратино (ok), 31-Дек-13, 12:50
	> Поддержка последней версии python2.7 закончится через год, рискуешь остаться с устаревшими знаниями. А почему бы просто не оставить 2.7 в покое? Работает? Работает. Устраивает? Устраивает. Стабилен? Как железобетон. Так зачем менять шило на мыло, если необходимости в этом НЕТ? ПРИЧИНУ, ПРИЧИНУ я могу услышать?
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	38. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+7 +/–
	Сообщение от Аноним (-), 31-Дек-13, 13:23
	> ПРИЧИНУ я могу услышать? Да. Если разработчики ЯП могут решать за хипстеров как правильно форматировать код, они уж тем более могут решить какая версия их языка - кошерная. А остальные могут идти в пень и майнтайнить свой бидон2 сами.
	Ответить | Правка | Наверх | Cообщить модератору

	57. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от pavlinux (ok), 31-Дек-13, 14:58
	systemd уже удалил?
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

	60. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от бедный буратино (ok), 31-Дек-13, 15:21
	ещё не ставил всё жду, когда 72 мб несистемд-кода под системд руки дойдут портировать
	Ответить | Правка | Наверх | Cообщить модератору

	141. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Аноним (-), 01-Янв-14, 19:34
	> ещё не ставил > всё жду, когда 72 мб несистемд-кода под системд руки дойдут портировать Что у тебя за код, который надо портировать под systemd? Если ты говоришь про инит-скрипты, но они без изменений продолжают работать.
	Ответить | Правка | Наверх | Cообщить модератору

	89. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+2 +/–
	Сообщение от jOKer (ok), 31-Дек-13, 21:35
	>Поддержка последней версии python2.7 закончится через год На самом деле, это и называется "ставить телегу впереди лошади"! Потому что мы должны уходить от платформы 2.7 не потому что заканчивается время ее поддержки, а потому что есть лучший вариант, из-за которого время поодержки и заканчивается. Но тут вот собака и порылась: я лично не вижу чем ветка три так кардинально лучше. Напротив, я вижу чем она хуже. Я вижу что ряд востребованных проектов не работает на ней, и никто и не собирается сделать им альтернативу. Про глобальную блокировку (костыль ее создателям в ухо!!!!) в новости сказано. Но сказно еще мало, потому что до полноценного ООП питону как до луны пешком! Ибо перегрузки функций как нет,  так и нет... А между тем уже три версии платформы 3.х реализнулись! И в чем, звиняюсь, их профит?! А ни в чем. Точнее только том, что "время поддержки платформы 2.7 истекло"
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	90. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–3 +/–
	Сообщение от myhand (ok), 31-Дек-13, 21:59
	>>Поддержка последней версии python2.7 закончится через год > На самом деле, это и называется "ставить телегу впереди лошади"! Потому что > мы должны уходить от платформы 2.7 не потому что заканчивается время > ее поддержки, а потому что есть лучший вариант Ну да.  Есть лучший вариант, для которого срок поддержки не заканчивается. Проблемы индейцев, которые до сих пор не удосужились подумать об обновлении - это именно проблемы этих индейцев.  Политика релизов - часть правил игры, а не то что меняется по желанию левой пятки анонимного интерпраизнутого индуса. > Но тут вот собака и порылась: я лично не вижу чем ветка > три так кардинально лучше? Тебе роскомнадзор помешал What’s New осилить? > Я вижу что ряд востребованных проектов не работает на ней Например? > Про глобальную блокировку (костыль ее создателям в ухо!!!!) в новости сказано. Где-то Гвидо отмечал, что упоминание GIL - признак примитивного троллинга.  Кажется, вот: http://www.youtube.com/watch?v=EBRMq2Ioxsc "Так-то вот" (ц) > потому что до полноценного ООП питону как до луны пешком! Что за зверь такой, "полноценное ООП"?  "Как в C++" (тм) что-ли?  Ох, малыш, уши той приплюснутой методички, по которой тебя в ПТУ учили "погроммированию" - торчат из этого "ООП" :)
	Ответить | Правка | Наверх | Cообщить модератору

	91. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от jOKer (ok), 31-Дек-13, 22:17
	>Ну да.  Есть лучший вариант, для которого срок поддержки не заканчивается. Так об этом и речь. В чем его "лучшесть"?! >Например? На пример это - RestrictedPython. Не вижу альтернативы. А между тем его функционал мне лично очень нужен. >Где-то Гвидо отмечал, что упоминание GIL - признак примитивного троллинга. А Гвидо не отмечал, что на данный момент существует минимум три решения (multiprocessing, parallel_python и gevent) что бы проблему затронутую в этом  "приминитивном троллинге" хоть как-то разрулить на практике, нет? Сцуко, вам бы с Гвидо хоть один раз столкнуться с задачами которые Яндекс дает явовцам в качетве разминки на много-поточность (включая и предельное время исполнения) и вы бы пели по другому! >Что за зверь такой, "полноценное ООП"? Вообще-то этого зверя хорошо определил Страуструп. Довольно понятно опредилил. Таким образом, что можно разобраться даже троллям младшего школьного возраста.
	Ответить | Правка | Наверх | Cообщить модератору

	102. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–1 +/–
	Сообщение от myhand (ok), 01-Янв-14, 00:03
	>>Ну да.  Есть лучший вариант, для которого срок поддержки не заканчивается. > Так об этом и речь. В чем его "лучшесть"?! Hint: читай What’s New.  Могу дать ссылку на перевотчик, если есть трудности с буржуйским. >>Например? > На пример это - RestrictedPython. Не вижу альтернативы. А между тем его > функционал мне лично очень нужен. Вы обещали пример "востребованного проекта".  Единственный критерий востребованности - "нужон лично jOKer"?  Конкретно данный проект не обновлялся более трех лет.  Это какая-то альтернативная востребованность... >>Где-то Гвидо отмечал, что упоминание GIL - признак примитивного троллинга. > А Гвидо не отмечал, что на данный момент существует минимум три решения > (multiprocessing, parallel_python и gevent) что бы проблему затронутую в этом   > "приминитивном троллинге" хоть как-то разрулить на практике, нет? Примитивность данного варианта троллинга - в преукрашении важности проблемы.  Ну а на тему существования решений - дайте ссылку на баги/активные pep. >>Что за зверь такой, "полноценное ООП"? > Вообще-то этого зверя хорошо определил Страуструп. С++ ПТУ, я ж угадал :)  Не обижайтесь, это правда.  По писаниям Страуструпа о языке C++ представление составить вполне можно.  Но о ООП - категорически рекоммендуется почитать что-то еще, причем не прибитое гвоздями к  C++.  Даже какой-нибудь SICP.  Все-ж scheme - это не статически типизированный язык, как и Python, в отличие от...
	Ответить | Правка | Наверх | Cообщить модератору

	116. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+2 +/–
	Сообщение от jOKer (ok), 01-Янв-14, 02:04
	>Hint: читай What’s New.  Могу дать ссылку на перевотчик, если есть трудности с буржуйским. В твоем "первоисточнике" сказано о новшествах, но ничего не сказано о кллиер-фиче. Как говорится, почуствуйте разницу. Вообще-то, у меня есть суровое ощущение, что в ветке 3.х минорные фичи наровят выдать за мажорные. Ну, а мажорных - нет вовсе. >Единственный критерий востребованности - "нужон лично jOKer" Ну если вы проблему исполнения питонового скрипта в окружении, с явно заданными ограничениями, называете "нужон лично jOKer" - то я вас поздравляю. А так если что: попробуйте исполняющимуся скрипту в ветке 3.х ограничить доступ к перменным его родителя. А так же до кучи и к его функциям... ну и блокировать механизм импорта тоже. А как сделаете... ну вот тогда мы и будем говорить "нужон лично jOKer" этот проект или все же он "нужон всем". >Примитивность данного варианта троллинга - в преукрашении важности проблемы.  Ну а на тему существования решений - дайте ссылку на баги/активные pep. Достаточно с вас и того, что на нагруженные много-поточные приложения тот же Яндекс даже и не собирается приглашать питонятников. Да и ни кто не собирается. Ибо занятие глубоко бесперспективное, потому что когда на довольно стандартной задачке в скомпилированной жабе время исполения - пара секунд, а в питоне из-за "преукрашеной проблемы" около часа... Ну... так получилось, да? >С++ ПТУ, я ж угадал :) Я так понимаю, что ваши догадки - прямо по Фрейду, не?
	Ответить | Правка | Наверх | Cообщить модератору

	117. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–2 +/–
	Сообщение от myhand (ok), 01-Янв-14, 02:46
	>>Hint: читай What’s New.  Могу дать ссылку на перевотчик, если есть трудности с буржуйским. > В твоем "первоисточнике" сказано о новшествах, но ничего не сказано о кллиер-фиче. Это же не пресс-релиз от ентырпрайза.  Я могу только гадать о том, что конкретно подходит под неизвестные критерии jOKer. Наверно, уже было в треде - нормальная поддержка юникода, не? >>Единственный критерий востребованности - "нужон лично jOKer" > Ну если вы проблему исполнения питонового скрипта в окружении, с явно заданными > ограничениями, называете "нужон лично jOKer" - то я вас поздравляю. А кому еще?  Объективных критериев нужности - я пока не увидел.  На то, что проект не обновляется три с лишним года - уже указал. >>Примитивность данного варианта троллинга - в преукрашении важности проблемы.  Ну а на тему существования решений - дайте ссылку на баги/активные pep. > Достаточно с вас и того, что на нагруженные много-поточные приложения тот же > Яндекс даже и не собирается приглашать питонятников. Мне начхать на Яндекс.  Ссылок нету, так и запишем. >>С++ ПТУ, я ж угадал :) > Я так понимаю, что ваши догадки - прямо по Фрейду, не? Догадка была по упоминанию "полноценного ООП", без попыток дефиниции такого неизвестного науке зверя.  Откуда следовало что под ООП jOKer понимает, скорее всего, реализацию данной парадигмы в каком-то конкретном ЯП.  Как учат "программированию" в современных ПТУ - я приблизительно представляю. В общем, какая разница - ежели я в итоге угадал?
	Ответить | Правка | Наверх | Cообщить модератору

	107. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok), 01-Янв-14, 00:48
	> А Гвидо не отмечал, что на данный момент существует минимум три решения (multiprocessing, parallel_python и gevent) что бы проблему затронутую в этом  "приминитивном троллинге" хоть как-то разрулить на практике, нет? Херню несёшь, ничего из этого не решает проблему с GIL. Пока есть только два направления - STM (software transactional memory) и в каком-то виде быть может stackless python.
	Ответить | Правка | К родителю #91 | Наверх | Cообщить модератору

	111. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от jOKer (ok), 01-Янв-14, 01:20
	>ничего из этого не решает проблему с GIL "The most simple and common way to write parallel applications for SMP computers is to use threads. Although, it appears that if the application is computation-bound using 'thread' or 'threading' python modules will not allow to run python byte-code in parallel. The reason is that python interpreter uses GIL (Global Interpreter Lock) for internal bookkeeping. This lock allows to execute only one python byte-code instruction at a time even on an SMP computer.     PP module overcomes this limitation and provides a simple way to write parallel python applications. Internally ppsmp  uses processes and IPC (Inter Process Communications) to organize parallel computations. All the details and complexity of the latter are completely taken care of, and your application just submits jobs and retrieves their results (the easiest way to write parallel applications)." http://www.parallelpython.com/ Остальное мне просто лениво цитировать. Читай сам, ОК?
	Ответить | Правка | Наверх | Cообщить модератору

	142. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+1 +/–
	Сообщение от Аноним (-), 01-Янв-14, 19:44
	>> А Гвидо не отмечал, что на данный момент существует минимум три решения (multiprocessing, parallel_python и gevent) что бы проблему затронутую в этом  "приминитивном троллинге" хоть как-то разрулить на практике, нет? > Херню несёшь, ничего из этого не решает проблему с GIL. Пока есть > только два направления - STM (software transactional memory) и в каком-то > виде быть может stackless python. Херню несешь ты. STM - это всего лишь инструмент, без разницы, будешь ли ты по коду питона расбрасывать подсистемные мьютексы или городить проверки состояний общих переменных, сам по себе GIL магически не исчезнет. Тем более, что STM в ряде случаев хуже по производительности, чем явные блокировки.
	Ответить | Правка | К родителю #107 | Наверх | Cообщить модератору

	92. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от jOKer (ok), 31-Дек-13, 22:32
	Кстати, это я еще не касался разных "приятных мелочей" связанных с импортом. Например импорт пакета по явно пределенному пути до каталога, Три версии ветки 3.х есть... функционал _востребован_..... ГДЕ?!!!
	Ответить | Правка | К родителю #90 | Наверх | Cообщить модератору

	125. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+1 +/–
	Сообщение от Кир (?), 01-Янв-14, 04:51
	Я бы не советовал так нарываться на рифму. С новым годом!
	Ответить | Правка | Наверх | Cообщить модератору

	144. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+7 +/–
	Сообщение от Аноним (-), 01-Янв-14, 19:54
	> Где-то Гвидо отмечал, что упоминание GIL - признак примитивного троллинга. Ну это вообще ПУШКА. Твой Гвидо и его питонодети за 20 лет ниасилили написать нормальный рантайм, а когда им на это указывают - это видите ли тороллинг. /0
	Ответить | Правка | К родителю #90 | Наверх | Cообщить модератору

	258. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Я (??), 08-Янв-14, 00:09
	>> Где-то Гвидо отмечал, что упоминание GIL - признак примитивного троллинга. > Ну это вообще ПУШКА. Твой Гвидо и его питонодети за 20 лет > ниасилили написать нормальный рантайм, а когда им на это указывают - > это видите ли тороллинг. /0 Осталось назвать скриптовый язык без GIL, тогда будет все в порядке.
	Ответить | Правка | Наверх | Cообщить модератору

	368. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Аноним (-), 21-Янв-14, 21:29
	>>> Где-то Гвидо отмечал, что упоминание GIL - признак примитивного троллинга. >> Ну это вообще ПУШКА. Твой Гвидо и его питонодети за 20 лет >> ниасилили написать нормальный рантайм, а когда им на это указывают - >> это видите ли тороллинг. /0 > Осталось назвать скриптовый язык без GIL, тогда будет все в порядке. Google: JRuby
	Ответить | Правка | Наверх | Cообщить модератору

	369. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 21-Янв-14, 23:09
	>>>> Где-то Гвидо отмечал, что упоминание GIL - признак примитивного троллинга. >>> Ну это вообще ПУШКА. Твой Гвидо и его питонодети за 20 лет >>> ниасилили написать нормальный рантайм, а когда им на это указывают - >>> это видите ли тороллинг. /0 >> Осталось назвать скриптовый язык без GIL, тогда будет все в порядке. > Google: JRuby Школота, это что, интерпретатор, по-твоему?  JPython тоже не имеет GIL.
	Ответить | Правка | Наверх | Cообщить модератору

	370. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Аноним (-), 21-Янв-14, 23:34
	ага. А ещё оно 2.х-only, кстати Ещё раз, медленно: Ruby -- скриптовый язык. Для него есть рантайм без GIL. Ты ведь это спрашивал?
	Ответить | Правка | Наверх | Cообщить модератору

	371. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 22-Янв-14, 15:58
	> ага. А ещё оно 2.х-only, кстати Ага не видит принципиальной разницы между JRuby и CRuby (в котором, кстати, тоже есть GIL)?  Ну а что касается версий - JRuby тоже не все, вроде, поддерживает, нет? > Ещё раз, медленно: Ruby -- скриптовый язык. Для него есть рантайм без > GIL. Ты ведь это спрашивал? Повторяю, для Python тоже есть *такой рантайм без GIL* (даже несколько).  Только, подозреваю, спрашивали тебя не про это.
	Ответить | Правка | Наверх | Cообщить модератору

	372. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Аноним (-), 22-Янв-14, 17:16
	>> ага. А ещё оно 2.х-only, кстати > Ага не видит принципиальной разницы между JRuby и CRuby (в котором, кстати, > тоже есть GIL)?  Ну а что касается версий - JRuby > тоже не все, вроде, поддерживает, нет? 1.8.7 + 1.9.3 + пока недопиленная 2.0 в одном рантайме. Этого достаточно на практике и уж всяко разнообразней, чем джитоновое "2.7 и ничего больше". >> Ещё раз, медленно: Ruby -- скриптовый язык. Для него есть рантайм без >> GIL. Ты ведь это спрашивал? > Повторяю, для Python тоже есть *такой рантайм без GIL* (даже несколько).   > Только, подозреваю, спрашивали тебя не про это. Там человеку вообще непонятна разница между рантаймом и яп. Пусть погуглит уж, не лезь.
	Ответить | Правка | Наверх | Cообщить модератору

	373. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Аноним (-), 22-Янв-14, 17:45
	> 1.8.7 + 1.9.3 + пока недопиленная 2.0 в одном рантайме. Этого достаточно > на практике и уж всяко разнообразней, чем джитоновое "2.7 и ничего > больше". Апд: как оказвлось, в джитоне 2.5 и всё (2.6 вышел в 2008). Т.е. проект протухший.
	Ответить | Правка | Наверх | Cообщить модератору

	374. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 22-Янв-14, 18:22
	Так людям нужен python без GIL (IronPython, имхо, востребован не больше).  А вот PyPy - набирает популярность, хотя этот рантайм не лишен GIL. Понятное дело, Гвидо о троллинге в контексте упоминания GIL - говорит больше в шутку.  Но в каждой шутке есть доля шутки...
	Ответить | Правка | Наверх | Cообщить модератору

	9. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+3 +/–
	Сообщение от Аноним (-), 31-Дек-13, 11:24
	На энтом нашем перле давным-давно поняли эти простые истины, и Perl6 полагают как: a) другой язык. Официально говорится, что Perl6 != Perl. b) весьма отдалённую перспективу. Ковыряют его и ковыряют, никто никого никуда не гонит.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	16. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Andrey Mitrofanov (?), 31-Дек-13, 11:35
	> На энтом нашем перле давным-давно поняли эти простые истины, и Perl6 полагают Нудк, 2->3 это вам не 5->6. Плюс мелочи вроде никс-хакеры из прошлого века совсем не гордые владельцы макбуков и гитхаб-кодиков.
	Ответить | Правка | Наверх | Cообщить модератору

	26. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok), 31-Дек-13, 12:11
	На Perl6 этого как раз не поняли, ибо он так и остался мёртворождённым проектом. Делать ещё один кусок гогна с поломкой вообще всех совместимостей когда основная ветка почти подохла и интерес к перлу ниже плинтуса совсем тупо. Если делаешь "другой" язык, то и называй его иначе. Тогда мб perl6 хоть как-то бы полетел.
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	33. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–2 +/–
	Сообщение от IMHO (?), 31-Дек-13, 12:55
	Perl6 == reg. exp.
	Ответить | Правка | Наверх | Cообщить модератору

	55. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+1 +/–
	Сообщение от Аноним (-), 31-Дек-13, 14:49
	>Если делаешь "другой" язык, то и называй его иначе. Тогда мб perl6 хоть как-то бы полетел. Perl 6 => Harbor.
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	86. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Q2W (?), 31-Дек-13, 21:06
	Потеря интереса к перлу у тебя лично вовсе не означает потерю интереса к перлу у всех остальных. Потеря интереса к перлу - миф.
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	88. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 31-Дек-13, 21:25
	> Потеря интереса к перлу - статистика.
	Ответить | Правка | Наверх | Cообщить модератору

	158. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Michael Shigorin (ok), 02-Янв-14, 13:36
	> На энтом нашем перле давным-давно поняли эти простые истины http://ftp.linux.kiev.ua/pub/conference/2013/video/learn-per... http://ftp.linux.kiev.ua/pub/conference/2013/reports/shamatr... :]
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	37. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–1 +/–
	Сообщение от Аноним (-), 31-Дек-13, 13:22
	> а ПОЧЕМУ люди должны переходить на python 3, собственно? Потому что разработчики бидона так решили. А всяких хомяковатых хипстеров которые на этом программят по жизни спросить как обычно забудут. > Кто не захочет - пусть пользуется ридным питоном. Э не, у хомяков так не делается. Если уж форматирование кода принудительно навязали, заставить апгрейдиться на новую, расово верную версию - вообще как 2 байта переслать.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	77. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–1 +/–
	Сообщение от Аноним (-), 31-Дек-13, 18:39
	> Если уж форматирование кода принудительно навязали Да угомонитесь вы уже с форматированием. Это вполне хорошая идея заставить форматировать код с помощью языка.
	Ответить | Правка | Наверх | Cообщить модератору

	97. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–1 +/–
	Сообщение от Аноним (-), 31-Дек-13, 23:05
	> Да угомонитесь вы уже с форматированием. Это вполне хорошая идея заставить форматировать > код с помощью языка. Отличная идея, ведь быдлo надо ставить в стойло. А мне не очень нравится идея что после пары нажатий бэкспейса не в том месте программы - все остается синтаксически валидным, никакой ругани нет, но логика отъезжает нафиг, при том не сильно очевидным образом. К тому же претензии на то что авторы языка лучше вообще всех остальных знают как форматировать код - выдают некислые вопросы насчет их ЧСВ. И судя по сабжу - с ЧСВ у них таки порядок. В том плане что для его утешения они готовы все до основания, и затем...
	Ответить | Правка | Наверх | Cообщить модератору

	106. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+1 +/–
	Сообщение от myhand (ok), 01-Янв-14, 00:28
	>> Да угомонитесь вы уже с форматированием. Это вполне хорошая идея заставить форматировать >> код с помощью языка. > Отличная идея, ведь быдлo надо ставить в стойло. Не нравится - не ешь.  Кто и когда тебя заставлял?  Окружили, бедного, в подворотне питонисты и давай...  Ставить в стоило. Факт тот, что эта идея работает, делая всякие скобочки, ; и т.п. - ненужными и/или опциональными.
	Ответить | Правка | Наверх | Cообщить модератору

	124. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Аноним (-), 01-Янв-14, 04:49
	> Не нравится - не ешь.  Кто и когда тебя заставлял?   Не ем. Но какие-то гомняшки все-таки иногда пытаются залететь там и тут. > - ненyжными и/или опциональными. Ну да, и ноги у тебя тоже опциональны: если их отпилить, ты скорее всего все-таки не умрешь. Правда вот я не уверен что ты с оптимизмом воспримешь инициативу избавить тебя от "лишних" ног.
	Ответить | Правка | Наверх | Cообщить модератору

	130. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–4 +/–
	Сообщение от myhand (ok), 01-Янв-14, 14:54
	>> - ненyжными и/или опциональными. > Ну да, и ноги у тебя тоже опциональны Уныл ты, троллоло.  Ноги тебе нужны, чтобы ходить (зато голова, скорее всего - точно опциональна!  ты попробуй).  "Скобочки", как выяснилось, не нужны вовсе - люди замечательно ходя^Wпрограммируют без них.
	Ответить | Правка | Наверх | Cообщить модератору

	159. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Michael Shigorin (ok), 02-Янв-14, 13:41
	>> Ну да, и ноги у тебя тоже опциональны > "Скобочки", как выяснилось, не нужны вовсе > - люди замечательно ходя^Wпрограммируют без них. Так ведь и без ног польку-бабочку иные танцевали.  Только лучше бы с ногами. Применительно к интерпретируемым языкам эээ... специфический синтаксис вроде питона обрезает такую полезнейшую штуку как однострочные скрипты (не те, где строчка в килобайт, а где в несколько слов).  Т.е. остаются лишь наиболее односложные варианты вроде #62.
	Ответить | Правка | Наверх | Cообщить модератору

	169. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 02-Янв-14, 16:08
	>>> Ну да, и ноги у тебя тоже опциональны >> "Скобочки", как выяснилось, не нужны вовсе >> - люди замечательно ходя^Wпрограммируют без них. > Так ведь и без ног польку-бабочку иные танцевали. Так с ногами!  Хоть и с искусственными.   > Применительно к интерпретируемым языкам эээ... специфический синтаксис вроде питона обрезает > такую полезнейшую штуку как однострочные скрипты Это вот такие что-ли: perl -e '$??s:;s:s;;$?::s;;=]=>%-{<-|}<&|`{;;y; -/:-@[-`{-};`-{/" -;;s;;$_;see' ? :)
	Ответить | Правка | Наверх | Cообщить модератору

	187. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–1 +/–
	Сообщение от Аноним (-), 03-Янв-14, 05:44
	> Это вот такие что-ли: Тут Шигорин как-то приводил пример на питоне, ничем не хуже. С переменными на японском языке и прочими прелестями. Такой пиндец читаемый код был. На  его фоне этот код, пожалуй, не так уж страшен..
	Ответить | Правка | Наверх | Cообщить модератору

	203. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 03-Янв-14, 12:26
	>> Это вот такие что-ли: > Тут Шигорин как-то приводил пример на питоне, ничем не хуже. По пословице - свинья грязи найдет.  Каку можно написать на любом ЯП, не обязательно использовать brainfuck, кто-б сомневался. > На  его фоне этот код, пожалуй, не так уж страшен.. Смысл был в другом, хотелось конструктивного примера одновременно *полезного* и *читаемого* однострочника, который можно на Perl и нельзя на Python.
	Ответить | Правка | Наверх | Cообщить модератору

	233. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Michael Shigorin (ok), 07-Янв-14, 18:17
	>>> Это вот такие что-ли: >> Тут Шигорин как-то приводил пример на питоне, ничем не хуже. http://www.opennet.me/openforum/vsluhforumID3/87068.html#24 > По пословице - свинья грязи найдет. Вот и примите сей кубок как автор #169. :)
	Ответить | Правка | Наверх | Cообщить модератору

	238. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–1 +/–
	Сообщение от myhand (ok), 07-Янв-14, 21:25
	>>>> Это вот такие что-ли: >>> Тут Шигорин как-то приводил пример на питоне, ничем не хуже. > http://www.opennet.me/openforum/vsluhforumID3/87068.html#24 Ну и как *это* запустить?  Какая-то китайщина, невесть каким боком к питону относящаяся. >> По пословице - свинья грязи найдет. > Вот и примите сей кубок как автор #169. :) "Мопед не мой" (ц)
	Ответить | Правка | Наверх | Cообщить модератору

	296. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Michael Shigorin (ok), 08-Янв-14, 04:14
	> Ну и как *это* запустить?  Какая-то китайщина, невесть каким боком к > питону относящаяся. Вы же вроде претендовали чуть ли не на взрослого человека, а два шага к ответу сделать оказались неспособны: http://reganmian.net/blog/2008/11/21/chinese-python-translat.../ >>> По пословице - свинья грязи найдет. >> Вот и примите сей кубок как автор #169. :) > "Мопед не мой" (ц) Неча на зеркало пенять (ц)
	Ответить | Правка | К родителю #238 | Наверх | Cообщить модератору

	305. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 08-Янв-14, 11:59
	>> Ну и как *это* запустить?  Какая-то китайщина, невесть каким боком к >> питону относящаяся. > Вы же вроде претендовали чуть ли не на взрослого человека, а два > шага к ответу сделать оказались неспособны: http://reganmian.net/blog/2008/11/21/chinese-python-translat.../ А зачем мне делать даже один шаг куда-то в кусты за "ответом"?  Этот кусок кода неспособен запустить CPython и его совместимые альтернативы, что я уже констатировал. Что-там у себя китайцы в гараже наклепали и как оно в результате читается - мне пофиг.  Ровно никакого отношения к питону это не имеет.
	Ответить | Правка | К родителю #296 | Наверх | Cообщить модератору

	307. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Andrey Mitrofanov (?), 08-Янв-14, 12:27
	> Неча на зеркало пенять (ц) s/(ц)/(пд)/
	Ответить | Правка | К родителю #296 | Наверх | Cообщить модератору

	277. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Аноним (-), 08-Янв-14, 01:44
	> По пословице - свинья грязи найдет. Да что там, на питоне 99% кода - именно оно. Да, Гвидо сделал шедевральную вещь: теперь быдлoкод красиво отформатирован. Правда, толка с этого ровно буй.
	Ответить | Правка | К родителю #203 | Наверх | Cообщить модератору

	259. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Я (??), 08-Янв-14, 00:12
	>> Это вот такие что-ли: > Тут Шигорин как-то приводил пример на питоне, ничем не хуже. С переменными > на японском языке и прочими прелестями. Такой пиндец читаемый код был. > На  его фоне этот код, пожалуй, не так уж страшен.. Только этот код, плод больной фантазии, не рабочий.
	Ответить | Правка | К родителю #187 | Наверх | Cообщить модератору

	250. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Я (??), 07-Янв-14, 23:21
	>>> Ну да, и ноги у тебя тоже опциональны >> "Скобочки", как выяснилось, не нужны вовсе >> - люди замечательно ходя^Wпрограммируют без них. > Так ведь и без ног польку-бабочку иные танцевали.  Только лучше бы > с ногами. > Применительно к интерпретируемым языкам эээ... специфический синтаксис вроде питона обрезает > такую полезнейшую штуку как однострочные скрипты (не те, где строчка в > килобайт, а где в несколько слов).  Т.е. остаются лишь наиболее > односложные варианты вроде #62. Шпесиалист!!! python -m platform python -m SimpleHTTPServer python  -c 'import math;a = [math.sin(x**2) for x in range(1, 101) if x % 5 != 0 ];print a'
	Ответить | Правка | К родителю #159 | Наверх | Cообщить модератору

	295. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Michael Shigorin (ok), 08-Янв-14, 04:10
	>> Т.е. остаются лишь наиболее односложные варианты вроде #62. > Шпесиалист!!! Писатель. > python  -c 'import math;a = [math.sin(x**2) for x in range(1, 101) if x % 5 != 0 ];print a'
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 31-Дек-13, 16:02
	> - python 2 почти идеален :) py2 НЕ идеален.  Кучу некрасивых вещей как раз и исправляет py3.  (Впрочем, добавляя новые, как 1/2=0.5 - вместо рациональных чисел...) > - python 2 уже работает, и работает замечательно Это - да.  Впрочем, это аргумент только для мертворожденных проектов.  "Слабал сайтик на PHP^WPython - и забыл." (ц) > - python 2 стабилен, как железобетон, никаких изменений в ближайшие 1000 лет не предвидится Зато предвидится прекращение поддержки.  ВНЕЗАПНО - это совсем скоро. > - python 2 банально быстрее Тому есть и доказательства?  Дайте, пожалуйста, ссылку (во блоги разной школоты можно не отсылать - подобное заявление вполне заслуживает публикации в хорошем реферируемом журнале).
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	93. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от jOKer (ok), 31-Дек-13, 22:44
	>Зато предвидится прекращение поддержки.  ВНЕЗАПНО - это совсем скоро. Слушай, тролленок,ты реально ДОСТАЛ. Скажи уже РАДИ ЧЕГО переходить на ветку три? Блин, приведи хоть один пример киллер-фичи ветки три и расслабься наконец!
	Ответить | Правка | Наверх | Cообщить модератору

	110. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–3 +/–
	Сообщение от myhand (ok), 01-Янв-14, 01:13
	Угу, полай сперва.  Если инвалид умственного труда читать так и не научился - это должны быть мои проблемы?
	Ответить | Правка | Наверх | Cообщить модератору

	118. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+1 +/–
	Сообщение от Аноним (-), 01-Янв-14, 04:04
	> Угу, полай сперва.   То есть по делу сказать нечего? Ожидаемо. Иди проспись хакир :)
	Ответить | Правка | Наверх | Cообщить модератору

	160. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Michael Shigorin (ok), 02-Янв-14, 13:42
	> Зато предвидится прекращение поддержки.  ВНЕЗАПНО - это совсем скоро. Да-да, некоторые здесь ещё помнят меры по продвижению apache2.
	Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

	223. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+1 +/–
	Сообщение от netch (ok), 07-Янв-14, 13:51
	>> - python 2 почти идеален :) > py2 НЕ идеален.  Кучу некрасивых вещей как раз и исправляет py3. >  (Впрочем, добавляя новые, как 1/2=0.5 - вместо рациональных чисел...) Если хочется по-старому целых, пишется 1//2, и я тут в общем согласен - операции "деление нацело" и "деление с float на выходе" принципиально различны, и их объединение в куче языков, начиная с Фортрана и Си, с правилами типа "если есть хоть один float на входе, то делим во float, иначе делим нацело" - диверсия. Изменение тут идёт в сторону, в которую и так Питон шёл изначально - поменьше неявных конверсий и различий поведения в зависимости от труднопредсказуемых факторов. А кому нужны именно рациональные числа - возьмёт соответствующий модуль, как mpq в GMP. > Зато предвидится прекращение поддержки.  ВНЕЗАПНО - это совсем скоро. Увы. Я уже заранее в ужасе от проблем перехода. >> - python 2 банально быстрее > Тому есть и доказательства?  Дайте, пожалуйста, ссылку (во блоги разной школоты > можно не отсылать - подобное заявление вполне заслуживает публикации в хорошем > реферируемом журнале). Я что-то не понимаю, зачем тут реферируемый журнал, когда рядом есть пример сравнения, проверяемый в три минуты: http://www.opennet.me/openforum/vsluhforumID3/93345.html#62 Да, это на очень частный случай возведения в степень (кстати, что там такого учудили?), но уже есть куда копать. А ещё то, что строки сейчас юникод, а это само по себе проблемнее (хотя бы encoding/decoding на каждом входе-выходе). У меня вот тема сетевого протокола, в котором если что-то за пределами ASCII и встречается, то только как неанализируемая нагрузка. Я уже в ужасе (пардон за повтор) от того, что придётся писать b'...' на каждом шагу...
	Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

	228. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 07-Янв-14, 14:49
	>>> - python 2 почти идеален :) >> py2 НЕ идеален.  Кучу некрасивых вещей как раз и исправляет py3. >>  (Впрочем, добавляя новые, как 1/2=0.5 - вместо рациональных чисел...) > Если хочется по-старому целых, пишется 1//2, и я тут в общем согласен > - операции "деление нацело" и "деление с float на выходе" принципиально различны Дело даже не в этом.  За старым операндом деления была внятная математическая структура.  А теперь одна из операций над целыми - выводит за пределы этого множества.  Более того, впилили еще один оператор на потеху "оверлоадчикам". > А кому нужны именно рациональные числа - возьмёт соответствующий модуль, как mpq в GMP. Ну а чем они так помешали в языке-то?  Трудность их включения минимальна, если bigint уже есть. >> Зато предвидится прекращение поддержки.  ВНЕЗАПНО - это совсем скоро. > Увы. Я уже заранее в ужасе от проблем перехода. Да нет никаких проблем у тех, кто не пишет чисто индуский^Wинтерпрайзнутый код а-ля "продал лоху и забыл". >>> - python 2 банально быстрее >> Тому есть и доказательства?  Дайте, пожалуйста, ссылку (во блоги разной школоты >> можно не отсылать - подобное заявление вполне заслуживает публикации в хорошем >> реферируемом журнале). > Я что-то не понимаю, зачем тут реферируемый журнал, когда рядом есть пример > сравнения, проверяемый в три минуты: > http://www.opennet.me/openforum/vsluhforumID3/93345.html#62 Затем, что от авторов статей требуется как минимум - умение тестировать.  Вы можете внятно описать *что* по вашему мнению "тестирует" этот код и почему?  Вы знаете, что range в py2 и py3 - две большие разницы? Вот как на самом деле: Python 2.7.3 (default, Jan  2 2013, 13:56:14) ... In [1]: %timeit 'l=list(xrange(100)); for i in l: pow(i,2)' 10000000 loops, best of 3: 50.6 ns per loop Python 3.2.3 (default, Feb 20 2013, 14:44:27) ... In [1]: %timeit 'l=list(range(100)); for i in l: pow(i,2)' 10000000 loops, best of 3: 29.5 ns per loop А вы говорите - зачем журнал... > Да, это на очень частный случай возведения в степень (кстати, что там > такого учудили?), но уже есть куда копать. Да.  Копать автору теста - в сторону What's New, как минимум.  А подозреваю - еще и в сторону остальной питоновской документации, начиная с tutorial... > У меня вот тема > сетевого протокола, в котором если что-то за пределами ASCII и встречается, > то только как неанализируемая нагрузка. Я уже в ужасе (пардон за > повтор) от того, что придётся писать b'...' на каждом шагу... Если вам приходится писать такие литералы "на каждом шагу" - что-то определенно не так с организацией кода.  Советую задуматься...
	Ответить | Правка | Наверх | Cообщить модератору

	234. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от netch (ok), 07-Янв-14, 19:19
	>>>> - python 2 почти идеален :) >>> py2 НЕ идеален.  Кучу некрасивых вещей как раз и исправляет py3. >>>  (Впрочем, добавляя новые, как 1/2=0.5 - вместо рациональных чисел...) >> Если хочется по-старому целых, пишется 1//2, и я тут в общем согласен >> - операции "деление нацело" и "деление с float на выходе" принципиально различны > Дело даже не в этом.  За старым операндом деления была внятная > математическая структура.  А теперь одна из операций над целыми - > выводит за пределы этого множества. И что, это принципиально плохо, если операция именно что объявлена как выводящая за эти пределы? Кто хочет оставаться в старых пределах - "//" к его услугам. >  Более того, впилили еще один оператор на потеху "оверлоадчикам". Не вижу ничего плохого. >> А кому нужны именно рациональные числа - возьмёт соответствующий модуль, как mpq в GMP. > Ну а чем они так помешали в языке-то?  Трудность их включения > минимальна, если bigint уже есть. А кому они там *реально* нужны? Использование рациональных - особая культура, под которую можно и применить соотв. разработку. >[оверквотинг удален] > - две большие разницы? > Вот как на самом деле: > Python 2.7.3 (default, Jan  2 2013, 13:56:14) > ... > In [1]: %timeit 'l=list(xrange(100)); for i in l: pow(i,2)' > 10000000 loops, best of 3: 50.6 ns per loop > Python 3.2.3 (default, Feb 20 2013, 14:44:27) > ... > In [1]: %timeit 'l=list(range(100)); for i in l: pow(i,2)' > 10000000 loops, best of 3: 29.5 ns per loop Проверяю. Python 2.7.6 (default, Jan  5 2014, 08:46:15) [GCC 4.2.1 20070831 patched [FreeBSD]] on freebsd9 >>> timeit.repeat('for i in list(range(100)): i**2', repeat=3, number=100000) [2.4664599895477295, 2.4887428283691406, 2.519745111465454] >>> timeit.repeat('for i in list(xrange(100)): i**2', repeat=3, number=100000) [2.7064688205718994, 2.629849910736084, 2.7545278072357178] Python 3.3.3 (default, Jan  6 2014, 08:43:57) [GCC 4.8.3 20131212 (prerelease)] on freebsd9 >>> timeit.repeat('for i in list(range(100)): i**2', repeat=3, number=100000) [6.169919643551111, 6.260113777592778, 7.007720373570919] >>> timeit.repeat('for i in range(100): i**2', repeat=3, number=100000) [5.9941876623779535, 6.649878324940801, 6.097862234339118] Система идентичная. Компилятор для 3-го даже лучше. В обоих вариантах время работы в третьем сильно больше. Что не так в моём тесте, по-Вашему? И как Вы так тестируете, что получается одинаково? Что такое "%timeit"? Я не знаю такого обозначения в самом Питоне. >> У меня вот тема >> сетевого протокола, в котором если что-то за пределами ASCII и встречается, >> то только как неанализируемая нагрузка. Я уже в ужасе (пардон за >> повтор) от того, что придётся писать b'...' на каждом шагу... > Если вам приходится писать такие литералы "на каждом шагу" - что-то определенно > не так с организацией кода.  Советую задуматься... Даже если это собрано в кило констант - всё равно неудобно. В Си, например, кто хочет работать именно с таким - wchar_t и функции над оным к его услугам.
	Ответить | Правка | Наверх | Cообщить модератору

	240. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 07-Янв-14, 21:34
	> А кому они там *реально* нужны? Использование рациональных - особая культура, под > которую можно и применить соотв. разработку. Да тем же, кому и большие целые нужны, не? >[оверквотинг удален] >> In [1]: %timeit 'l=list(xrange(100)); for i in l: pow(i,2)' >> 10000000 loops, best of 3: 50.6 ns per loop >> Python 3.2.3 (default, Feb 20 2013, 14:44:27) >> ... >> In [1]: %timeit 'l=list(range(100)); for i in l: pow(i,2)' >> 10000000 loops, best of 3: 29.5 ns per loop > Проверяю. > Python 2.7.6 (default, Jan  5 2014, 08:46:15) > [GCC 4.2.1 20070831 patched [FreeBSD]] on freebsd9 >>>> timeit.repeat('for i in list(range(100)): i**2', repeat=3, number=100000) :(  Ох, увы мне - еще один "проверяльщик". Вам за глупость уже оправдания нет - вас носом ткнули в то, что было неправильно в тестах предыдущего автора.  Как минимум, в один из моментов... "Десять отличий" искать не попрошу - но парочку принципиальных отличий между моими и вашими тестами - прошу найти и объяснить себе. > Что не так в моём тесте, по-Вашему? И как Вы так тестируете, > что получается одинаково? Одинаково не получается - у меня явно лидирует py3. > Что такое "%timeit"? Я не знаю такого обозначения в самом Питоне. Это макрос ipython.  Делает он приблизительно то же самое, что и timeit.repeat. >>> повтор) от того, что придётся писать b'...' на каждом шагу... >> Если вам приходится писать такие литералы "на каждом шагу" - что-то определенно >> не так с организацией кода.  Советую задуматься... > Даже если это собрано в кило констант - всё равно неудобно. "Кило констант" - таки многовато...
	Ответить | Правка | Наверх | Cообщить модератору

	242. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от netch (ok), 07-Янв-14, 21:50
	>> А кому они там *реально* нужны? Использование рациональных - особая культура, под >> которую можно и применить соотв. разработку. > Да тем же, кому и большие целые нужны, не? Видимо, таки "не". > :(  Ох, увы мне - еще один "проверяльщик". > Вам за глупость уже оправдания нет - вас носом ткнули в то, > что было неправильно в тестах предыдущего автора.  Как минимум, в > один из моментов... > "Десять отличий" искать не попрошу - но парочку принципиальных отличий между моими > и вашими тестами - прошу найти и объяснить себе. Нет, Вы уж, пожалуйста, объясните открытым текстом, раз уж мы такие "глупые". Заодно, если Вы каким-то образом модифицируете тесты для своего сравнения, объясните причину такой модификации. Я вот вижу, что Вы выделяете каждый раз список в отдельную переменную, но меня такой тест не устраивает, потому что писать каждый практический цикл в таком виде - значит задолбаться. Какое-то ещё отличие? >> Что такое "%timeit"? Я не знаю такого обозначения в самом Питоне. > Это макрос ipython.  Делает он приблизительно то же самое, что и > timeit.repeat. Предлагаю таки оставаться в пределах стандартных средств (и, соответственно, приму для сравнения только тесты на основе стандартных модулей и стандартного шелла - мне для работы никакие ipython нафиг не сдались). >>>> повтор) от того, что придётся писать b'...' на каждом шагу... >>> Если вам приходится писать такие литералы "на каждом шагу" - что-то определенно >>> не так с организацией кода.  Советую задуматься... >> Даже если это собрано в кило констант - всё равно неудобно. > "Кило констант" - таки многовато... Это уже сложность предметной области, увы.
	Ответить | Правка | Наверх | Cообщить модератору

	249. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 07-Янв-14, 23:20
	>>> А кому они там *реально* нужны? Использование рациональных - особая культура, под >>> которую можно и применить соотв. разработку. >> Да тем же, кому и большие целые нужны, не? > Видимо, таки "не". > Я вот вижу, что Вы выделяете каждый раз список > в отдельную переменную Таки заметили? :) Смотря что вы тестируете.  Если тестируете то, как работают степени - это необходимо.  Если сравниваете невесть что - конечно, это не надо.  Но и статью к публикации не возьмут ;)  Т.к. range в py2 и py3 - две большие разницы, как вам уже объясняли. Не думаю, что это существенно в данном случае, но таки... >>> Что такое "%timeit"? Я не знаю такого обозначения в самом Питоне. >> Это макрос ipython.  Делает он приблизительно то же самое, что и >> timeit.repeat. > Предлагаю таки оставаться в пределах стандартных средств (и, соответственно, приму для > сравнения только тесты на основе стандартных модулей и стандартного шелла - > мне для работы никакие ipython нафиг не сдались). Да пожалуйста.  Я ж не против мазохистов: $ python -m timeit -n 100000 -r 3 -s 'for i in range(100): pow(i,2)' 100000 loops, best of 3: 0.0419 usec per loop $ python3 -m timeit -n 100000 -r 3 -s 'for i in range(100): pow(i,2)' 100000 loops, best of 3: 0.027 usec per loop
	Ответить | Правка | Наверх | Cообщить модератору

	253. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от netch (ok), 07-Янв-14, 23:47
	>>>> А кому они там *реально* нужны? Использование рациональных - особая культура, под >>>> которую можно и применить соотв. разработку. >>> Да тем же, кому и большие целые нужны, не? >> Видимо, таки "не". >> Я вот вижу, что Вы выделяете каждый раз список >> в отдельную переменную > Таки заметили? :) Ещё бы. А что, это тут настолько важно? При том, что собственно сам список не используется? Если да, то как-то бессмысленно выставлять этот результат в качестве преимуществ 3.x, потому что он свидетельствует как раз о недостатке. Или, что само по себе включение ipython каким-то образом улучшает работу (например. меняет реализацию возведения в степень на быструю), или, что возведение в степень совместно с циклом тормозит. Например, в L1 кэш не влезает. Поэтому я хочу таки увидеть результаты 1) без ipython (ибо я такую штуку в своих работах не буду использовать) и 2) без выделения списка. Вот тогда сравнение будет честным. > Смотря что вы тестируете.  Если тестируете то, как работают степени - > это необходимо.  Если сравниваете невесть что - конечно, это не > надо.  Но и статью к публикации не возьмут ;)   > Т.к. range в py2 и py3 - две большие разницы, как > вам уже объясняли. Зато xrange() в py2 эквивалентно range() в py3, а range() в py2 - list(range()) в py3. По крайней мере сравнивать их надо именно так, что я и сделал. >>>> Что такое "%timeit"? Я не знаю такого обозначения в самом Питоне. >>> Это макрос ipython.  Делает он приблизительно то же самое, что и >>> timeit.repeat. >> Предлагаю таки оставаться в пределах стандартных средств (и, соответственно, приму для >> сравнения только тесты на основе стандартных модулей и стандартного шелла - >> мне для работы никакие ipython нафиг не сдались). > Да пожалуйста.  Я ж не против мазохистов: Это не мазохизм, а просьба о честном измерении:) > $ python -m timeit -n 100000 -r 3 -s 'for i in > range(100): pow(i,2)' > 100000 loops, best of 3: 0.0419 usec per loop > $ python3 -m timeit -n 100000 -r 3 -s 'for i in > range(100): pow(i,2)' > 100000 loops, best of 3: 0.027 usec per loop Пожалуйста, приведите 4 результата: * py2, range() * py2, xrange() * py3, list(range()) * py3, range() тогда сравним. И несколько запусков, выбрать средний из них результат (на глаз, но честно). Если у Вас будет заметное преимущество py3, тогда интересна платформа. Пока что у меня и на фре (показывал), и на линуксе py3 тормозит.
	Ответить | Правка | Наверх | Cообщить модератору

	257. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 08-Янв-14, 00:06
	> Ещё бы. А что, это тут настолько важно? Скорее всего - не важно, но тем не менее. > При том, что собственно сам список не используется? Используется в for.   > Поэтому я хочу таки увидеть результаты 1) без ipython (ибо я такую > штуку в своих работах не буду использовать) и 2) без выделения > списка. Вот тогда сравнение будет честным. Я вам дал эти результаты.  Самые что ни есть "штатные срЕдства", вот: >> $ python -m timeit -n 100000 -r 3 -s 'for i in >> range(100): pow(i,2)' >> 100000 loops, best of 3: 0.0419 usec per loop >> $ python3 -m timeit -n 100000 -r 3 -s 'for i in >> range(100): pow(i,2)' >> 100000 loops, best of 3: 0.027 usec per loop > Пожалуйста, приведите 4 результата: Лень уже.  Выше тесты видите - кто кого обогнал?  Богомерзкий ipython видите?  Достаточно штатные средства? > тогда сравним. И несколько запусков, выбрать средний из них результат (на глаз, > но честно). Разница - порядка той, что я указал, приблизительно в два раза (обгоняет таки py3). > Если у Вас будет заметное преимущество py3, тогда интересна платформа. Пока что > у меня и на фре (показывал), и на линуксе py3 тормозит. $ lsb_release -a No LSB modules are available. Distributor ID:    Debian Description:    Debian GNU/Linux 7.3 (wheezy) Release:    7.3 Codename:    wheezy $ uname -r 3.2.0-4-amd64
	Ответить | Правка | Наверх | Cообщить модератору

	297. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Michael Shigorin (ok), 08-Янв-14, 04:19
	>> Пожалуйста, приведите 4 результата: > Лень уже. Просто к сведению про Вашего оппонента: http://ftp.linux.kiev.ua/pub/Linux/xpandrx/highload_2011.pdf
	Ответить | Правка | Наверх | Cообщить модератору

	310. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 08-Янв-14, 12:45
	>>> Пожалуйста, приведите 4 результата: >> Лень уже. > Просто к сведению про Вашего оппонента: http://ftp.linux.kiev.ua/pub/Linux/xpandrx/highload_2011.pdf Что вы хотите этим сказать? Его просьбы я выполнил - привел бенчмарки, используя "штатные средствА".  Картина осталась прежняя - пусть объясняет.  А дополнительные сравнения с range/xrange/etc - мне не интересны, это я мимоходом прикопался.
	Ответить | Правка | Наверх | Cообщить модератору

	311. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Michael Shigorin (ok), 08-Янв-14, 16:34
	> Что вы хотите этим сказать? Что Валику давно уже есть дело до нагрузок и проблем, с которыми Вы и прочие scipy сорвавшиеся явно дела и близко не имеете.
	Ответить | Правка | Наверх | Cообщить модератору

	312. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 08-Янв-14, 16:40
	>> Что вы хотите этим сказать? > Что Валику давно уже есть дело до нагрузок Охотно верю, и? > с которыми Вы и прочие scipy сорвавшиеся явно дела и близко не имеете. Очередное бездоказательное и наивное заявление?
	Ответить | Правка | К родителю #311 | Наверх | Cообщить модератору

	313. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Michael Shigorin (ok), 08-Янв-14, 17:47
	>>> Что вы хотите этим сказать? >> Что Валику давно уже есть дело до нагрузок > Охотно верю, и? И соответственно воспринимать может быть конструктивней в этом ключе, а не на своё сворачивать (к слову о поисках под фонарём). >> с которыми Вы и прочие scipy сорвавшиеся явно дела и близко не имеете. > Очередное бездоказательное и наивное заявление? По походке видно.  Это даже не наезд, просто подковырка -- не объять всего.
	Ответить | Правка | К родителю #312 | Наверх | Cообщить модератору

	316. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от netch (ok), 09-Янв-14, 00:57
	>[оверквотинг удален] > вот: >>> $ python -m timeit -n 100000 -r 3 -s 'for i in >>> range(100): pow(i,2)' >>> 100000 loops, best of 3: 0.0419 usec per loop >>> $ python3 -m timeit -n 100000 -r 3 -s 'for i in >>> range(100): pow(i,2)' >>> 100000 loops, best of 3: 0.027 usec per loop >> Пожалуйста, приведите 4 результата: > Лень уже.  Выше тесты видите - кто кого обогнал?  Богомерзкий > ipython видите?  Достаточно штатные средства? Да, достаточно. Вы накойхер (фамилие такое) ключик -s добавили перед тестами, превратив тем самым весь этот цикл вокруг pow() в setup action, и сделав *пустую* рабочую команду? Приводим средство замера в норму - убираем ключик и повторяем. Для начала на FreeBSD/i386, Athlon64 3500+ (там же, где и прошлые тесты): $ python -m timeit -v -r 3 -n 100000 'for i in range(100): i**2' raw times: 2.53 2.48 2.45 100000 loops, best of 3: 24.5 usec per loop $ python3.3 -m timeit -v -r 3 -n 100000 'for i in range(100): i**2' raw times: 5.96 6.41 6 100000 loops, best of 3: 59.6 usec per loop Теперь на Linux/x86-64 (конкретно, это OpenSuSE 12.2), C2Q Q6600: $ python -m timeit -v -r 3 -n 100000 'for i in range(100): i**2' raw times: 1.11 1.11 1.11 100000 loops, best of 3: 11.1 usec per loop $ python3 -m timeit -v -r 3 -n 100000 'for i in range(100): i**2' raw times: 5 5 5 100000 loops, best of 3: 50 usec per loop (здесь питон 3.2) Такая же ось, но проц уже круть - i7-3770: $ python -m timeit -v -r 3 -n 100000 'for i in range(100): i**2' raw times: 0.548 0.548 0.548 100000 loops, best of 3: 5.48 usec per loop $ python3 -m timeit -v -r 3 -n 100000 'for i in range(100): i**2' raw times: 2.58 2.58 2.58 100000 loops, best of 3: 25.8 usec per loop Разницу видите? Вот это на честном измерении, а не том, что у Вас. Я надеюсь, что это у Вас таки была глупая ошибка - потому что альтернатива ещё хуже. > Разница - порядка той, что я указал, приблизительно в два раза (обгоняет > таки py3). Ну что, перепроверите по-нормальному? А заодно ещё пусть кто-нибудь отзовётся.
	Ответить | Правка | К родителю #257 | Наверх | Cообщить модератору

	317. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от netch (ok), 09-Янв-14, 01:00
	Вдогонку: если не i**2, а pow(i,2), разница поменьше (например, 74 против 41 на фрёвой машине), но всё равно в пользу py2, а не py3.
	Ответить | Правка | Наверх | Cообщить модератору

	318. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 09-Янв-14, 02:03
	>[оверквотинг удален] >>>> 100000 loops, best of 3: 0.0419 usec per loop >>>> $ python3 -m timeit -n 100000 -r 3 -s 'for i in >>>> range(100): pow(i,2)' >>>> 100000 loops, best of 3: 0.027 usec per loop >>> Пожалуйста, приведите 4 результата: >> Лень уже.  Выше тесты видите - кто кого обогнал?  Богомерзкий >> ipython видите?  Достаточно штатные средства? > Да, достаточно. Вы накойхер (фамилие такое) ключик -s добавили перед тестами, превратив > тем самым весь этот цикл вокруг pow() в setup action, и > сделав *пустую* рабочую команду? Мда.  Похоже на правду.  Видимо, лишний ключик не убил (то, что для модулей значение одноименных ключиков меняется - порой вот такие засады делает). $ python3 -m timeit -n 100000 -r 3 'for i in range(100): pow(i,2)' 100000 loops, best of 3: 86.1 usec per loop $ python -m timeit -n 100000 -r 3 'for i in xrange(100): pow(i,2)' 100000 loops, best of 3: 34.1 usec per loop А вот для бОльших целых (но все еще не bigint), похоже, ситуация обратная: $ python -m timeit -n 100000 -r 3 'for i in xrange(10000000000000,10000000000000+100): pow(i,2)' 100000 loops, best of 3: 271 usec per loop $ python3 -m timeit -n 100000 -r 3 'for i in range(10000000000000,10000000000000+100): pow(i,2)' 100000 loops, best of 3: 106 usec per loop Возможно, память мне изменяет, но кажется что в py3 что-то делали в сторону оптимизации умножения для больших целых.  Пока не удалось нагуглить на эту тему issues, что попали только в py3.
	Ответить | Правка | К родителю #316 | Наверх | Cообщить модератору

	321. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от netch (ok), 12-Янв-14, 12:11
	> Мда.  Похоже на правду.  Видимо, лишний ключик не убил (то, > что для модулей значение одноименных ключиков меняется - порой вот такие > засады делает). > $ python3 -m timeit -n 100000 -r 3 'for i in range(100): > pow(i,2)' > 100000 loops, best of 3: 86.1 usec per loop > $ python -m timeit -n 100000 -r 3 'for i in xrange(100): > pow(i,2)' > 100000 loops, best of 3: 34.1 usec per loop О, спасибо. Значит, уже знаем, как мерять правильно, и чтобы данные тестов сходились. (Заодно у меня ещё меньше доверия к ipython.) Теперь осталось выбрать правильные тесты. > Возможно, память мне изменяет, но кажется что в py3 что-то делали в > сторону оптимизации умножения для больших целых.  Пока не удалось нагуглить > на эту тему issues, что попали только в py3. У меня основная тема таки работа со строками и байтовыми последовательностями (что поделаешь, SIP). И вот тут картина тоже достаточно грустная. Например, эмуляция операций со строками в размере, сравнимом с командными пакетами: $ python2 -m timeit -r 7 -n 100000 -s 'a="a"*1000' 'a+"b"*200+"c"*100' 100000 loops, best of 7: 1.35 usec per loop $ python3.3 -m timeit -r 7 -n 100000 -s 'a="a"*1000' 'a+"b"*200+"c"*100' 100000 loops, best of 7: 1.55 usec per loop $ python3.3 -m timeit -r 7 -n 100000 -s 'a=b"a"*1000' 'a+b"b"*200+b"c"*100' 100000 loops, best of 7: 1.4 usec per loop $ python2 -m timeit -r 7 -n 100000 -s 'a="a"*50+"\n"; p=a*30' 'p.split()' 100000 loops, best of 7: 8.03 usec per loop $ python3.3 -m timeit -r 7 -n 100000 -s 'a="a"*50+"\n"; p=a*30' 'p.split()' 100000 loops, best of 7: 8.23 usec per loop $ python3.3 -m timeit -r 7 -n 100000 -s 'a=b"a"*50+b"\n"; p=a*30' 'p.split()' 100000 loops, best of 7: 7.3 usec per loop Даже на bytes py3 местами медленнее py2 (и это последние версии). А на строках вообще имеем процентов 20 падения. Я попробовал сделать перевод кода основного проекта на py3. Ещё не закончил (есть идиотские грабли типа:       File "/usr/lib64/python3.2/shelve.py", line 95, in __iter__     for k in self.dict.keys():       File "/usr/lib64/python3.2/shelve.py", line 70, in closed     raise ValueError('invalid operation on closed shelf')     ValueError: invalid operation on closed shelf клянусь мириадами воплощений Митры, я его не закрывал!), но уже ясно, что в разумное время осилить это можно только в варианте, когда конверсия str<->bytes делается на границе сетевых транспортов (и в странных местах типа base64), а внутри в SIP стеке уже только str. Второй этап конверсии придётся делать уже позже, и там свои грабли (например, дико неудобно, что для bytes нет '%' и format() - приходится всё переписывать на ручные сложения строк и конверсии форматов). Ещё совершенно неожиданно всплыло, что проверка типа "x > 0", где x == None, выдаёт молчаливый False на py2, но исключение на py3. Ни в одном описании граблей перевода я не заметил предупреждения про такое. Документация по переводу местами сильно врёт (например, "In Python 3, though, there is only a string representation." (из секции про __unicode__)) - но есть же __bytes__. В одном месте нарвался, как оно мне вычисляло необходимость создать 4.75 тредов:))) (да-да, замена на "//" исправила).
	Ответить | Правка | Наверх | Cообщить модератору

	335. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 12-Янв-14, 21:34
	> и чтобы данные тестов сходились. Так я бы не сказал, что они "сходятся".  Для больших чисел у меня получилась обратная картина. > У меня основная тема таки работа со строками и байтовыми последовательностями (что > поделаешь, SIP). > И вот тут картина тоже достаточно грустная. Например, эмуляция операций со строками > в размере, сравнимом с командными пакетами: > $ python2 -m timeit -r 7 -n 100000 -s 'a="a"*1000' 'a+"b"*200+"c"*100' > 100000 loops, best of 7: 1.35 usec per loop > $ python3.3 -m timeit -r 7 -n 100000 -s 'a="a"*1000' 'a+"b"*200+"c"*100' > 100000 loops, best of 7: 1.55 usec per loop > $ python3.3 -m timeit -r 7 -n 100000 -s 'a=b"a"*1000' 'a+b"b"*200+b"c"*100' > 100000 loops, best of 7: 1.4 usec per loop У меня получается так: $ python2 -m timeit -r 7 -n 100000 -s 'a="a"*1000' 'a+"b"*200+"c"*100' 100000 loops, best of 7: 0.969 usec per loop vs $ python3 -m timeit -r 7 -n 100000 -s 'a=b"a"*1000' 'a+b"b"*200+b"c"*100' 100000 loops, best of 7: 1.18 usec per loop Не сказал бы, что разница велика, если она вообще тут измерима. > Ещё совершенно неожиданно всплыло, что проверка типа "x > 0", где x > == None, выдаёт молчаливый False на py2, но исключение на py3. > Ни в одном описании граблей перевода я не заметил предупреждения про > такое. Ох уж эти мне песатели.  Читаем с выражением: http://docs.python.org/3.0/whatsnew/3.0.html#ordering-compar... Описание граблей в каком-то анонимном бложеке - может, конечно, быть полезным, но все-таки существует и официальная документация. > Документация по переводу местами сильно врёт (например, "In Python 3, though, there > is only a string representation." (из секции про __unicode__)) - но > есть же __bytes__. bytes - не string, это bytes.  Впрочем, я не готов гадать о какой конкретно "документации по переводу" идет речь.
	Ответить | Правка | К родителю #321 | Наверх | Cообщить модератору

	337. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от netch (ok), 12-Янв-14, 21:44
	>> и чтобы данные тестов сходились. > Так я бы не сказал, что они "сходятся".  Для больших чисел > у меня получилась обратная картина. Я имею в виду, что для одних и тех же тестов они очень сходны. Большие числа - это уже другой тест. >[оверквотинг удален] >> 100000 loops, best of 7: 1.55 usec per loop >> $ python3.3 -m timeit -r 7 -n 100000 -s 'a=b"a"*1000' 'a+b"b"*200+b"c"*100' >> 100000 loops, best of 7: 1.4 usec per loop > У меня получается так: > $ python2 -m timeit -r 7 -n 100000 -s 'a="a"*1000' 'a+"b"*200+"c"*100' > 100000 loops, best of 7: 0.969 usec per loop > vs > $ python3 -m timeit -r 7 -n 100000 -s 'a=b"a"*1000' 'a+b"b"*200+b"c"*100' > 100000 loops, best of 7: 1.18 usec per loop > Не сказал бы, что разница велика, если она вообще тут измерима. 20% разницы это не измеримо? Речь ведь о сотнях и тысячах тактов. А именно подобная манипуляция со строками составляет практически основную часть затрат. >> Ещё совершенно неожиданно всплыло, что проверка типа "x > 0", где x >> == None, выдаёт молчаливый False на py2, но исключение на py3. >> Ни в одном описании граблей перевода я не заметил предупреждения про >> такое. > Ох уж эти мне песатели.  Читаем с выражением: > http://docs.python.org/3.0/whatsnew/3.0.html#ordering-compar... 3.0? На дворе 3.3, а ветка 2.x после выпуска 3.0 тоже ушла. Сохранять проблемы перехода в доке по 3.0... Но спасибо, я раньше пользовался этим описанием, а потом как-то забылось за ненадобностью.
	Ответить | Правка | К родителю #335 | Наверх | Cообщить модератору

	344. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 12-Янв-14, 23:28
	>>> и чтобы данные тестов сходились. >> Так я бы не сказал, что они "сходятся".  Для больших чисел >> у меня получилась обратная картина. > Я имею в виду, что для одних и тех же тестов они > очень сходны. Большие числа - это уже другой тест. Тот же самый - возведение в степень, не виляйте :) > 20% разницы это не измеримо? Речь ведь о сотнях и тысячах тактов. Ближе к 10%, учитывая ваши тесты (впрочем, у меня py3.2).  Плюс, разброс, вот как-то так: $ python3 -m timeit -r 7 -n 100000 -s 'a=b"a"*1000' 'a+b"b"*200+b"c"*100' 100000 loops, best of 7: 1.22 usec per loop $ python3 -m timeit -r 7 -n 100000 -s 'a=b"a"*1000' 'a+b"b"*200+b"c"*100' 100000 loops, best of 7: 1.37 usec per loop > 3.0? На дворе 3.3, а ветка 2.x после выпуска 3.0 тоже ушла. > Сохранять проблемы перехода в доке по 3.0... В принципе, логично ведь поместить предупреждение о введенной несовместимости именно в соответствующем What's New? Документация, пардон, должна документировать текущее состояние.  Вполне нормальная практика - полистайте, к примеру, стандарты scheme.  О несовместимостях упоминается в тексте нерегулярно (в документации python тоже говорят о версиях, в которых добавлен тот или иной интерфейс, или объявлен устаревшим), а систематически это делается в специальной главе.
	Ответить | Правка | К родителю #337 | Наверх | Cообщить модератору

	347. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от netch (ok), 13-Янв-14, 00:40
	>> Я имею в виду, что для одних и тех же тестов они >> очень сходны. Большие числа - это уже другой тест. > Тот же самый - возведение в степень, не виляйте :) Но других чисел. Вы опять не хотите подумать, прежде чем отвечать. >> 20% разницы это не измеримо? Речь ведь о сотнях и тысячах тактов. > Ближе к 10%, учитывая ваши тесты (впрочем, у меня py3.2).  Плюс, > разброс, вот как-то так: > $ python3 -m timeit -r 7 -n 100000 -s 'a=b"a"*1000' 'a+b"b"*200+b"c"*100' > 100000 loops, best of 7: 1.22 usec per loop > $ python3 -m timeit -r 7 -n 100000 -s 'a=b"a"*1000' 'a+b"b"*200+b"c"*100' > 100000 loops, best of 7: 1.37 usec per loop OK, даже если это 10%, для моих задач это достаточно существенно, тем более что прогресс железа начал замедляться. >> 3.0? На дворе 3.3, а ветка 2.x после выпуска 3.0 тоже ушла. >> Сохранять проблемы перехода в доке по 3.0... > В принципе, логично ведь поместить предупреждение о введенной несовместимости именно в > соответствующем What's New? Это было логично до тех пор, пока не начался откат (например, разрешение префикса 'u' в 3.3). С этого момента надо заводить более актуальный список.
	Ответить | Правка | К родителю #344 | Наверх | Cообщить модератору

	350. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 13-Янв-14, 01:52
	> Но других чисел. Вы опять не хотите подумать, прежде чем отвечать. Я и отвечаю - с другими числами ваш тест показывает обратную картину. Или вот: $ python -m timeit -n 100000 -r 3 'for i in xrange(100): pow(i, 10)' 100000 loops, best of 3: 98.8 usec per loop $ python3 -m timeit -n 100000 -r 3 'for i in range(100): pow(i, 10)' 100000 loops, best of 3: 101 usec per loop Видимо, это все-таки как-то связано с удалением специального случая int, имевшегося в py2 (т.к. теперь только bigint aka long в py2).  Насколько это катастрофично - нужно судить по более представительным тестам. > Это было логично до тех пор, пока не начался откат (например, разрешение > префикса 'u' в 3.3). С этого момента надо заводить более актуальный список. Ну, это не ко мне.  Хотите поучить писать документацию - флаг вам в руки и http://bugs.python.org/ в помощь.  Жду патча. С какого боку после 3.3 данное место стало нелогичным?  Оно документирует отличия от предыдущего major-релиза? - Да.  Другие major-релизы 3.x ветки куда-то делись? - Нет.  Мне вот в дистрибутиве py3.2 прилетел.
	Ответить | Правка | К родителю #347 | Наверх | Cообщить модератору

	359. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от netch (ok), 13-Янв-14, 11:07
	>> Но других чисел. Вы опять не хотите подумать, прежде чем отвечать. > Я и отвечаю - с другими числами ваш тест показывает обратную картину. Верю. Я говорил про то, что для конкретных значений наши данные сошлись, и это было первое, что требовалось обеспечить - потому что Ваш наезд на mimimi@ был просто на результатах неверных измерений. А вот теперь можно начинать оценивать смысл конкретного теста с конкретными числами. И вот тут уже начинается расхождение по задачам. Для Ваших задач, вероятно, 10-е степени и числа порядка миллиона под ними это полезно. Для моих это нереальный случай, а вот арифметика с числами, грубо говоря, до 100 - значительно важнее (а цена работы со строками - ещё важнее). А на них у py3 просадка. >> Это было логично до тех пор, пока не начался откат (например, разрешение >> префикса 'u' в 3.3). С этого момента надо заводить более актуальный список. > Ну, это не ко мне.  Хотите поучить писать документацию - флаг > вам в руки и http://bugs.python.org/ в помощь.  Жду патча. Спасибо за доверие, но я на "show your code" не поведусь - работы много. Для себя я сформулировал принцип и собрал ссылки в нужную последовательность.
	Ответить | Правка | К родителю #350 | Наверх | Cообщить модератору

	361. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 13-Янв-14, 13:35
	> Верю. Я говорил про то, что для конкретных значений наши данные сошлись, > и это было первое, что требовалось обеспечить - потому что Ваш > наезд на mimimi@ был просто на результатах неверных измерений. Не только.  Если вы помните, я прикопался еще к range/xrange - и это было только началом... > Для моих это нереальный случай, а вот арифметика с числами, грубо > говоря, до 100 - значительно важнее (а цена работы со строками > - ещё важнее). А на них у py3 просадка. Охотно верю про суть ваших задач.  А вот "просадка" для "арифметики с числами" - требует все-таки более существенных доказательств. $ python3 -m timeit -n 100000 -r 3 'for i in range(1,100): i*i' 100000 loops, best of 3: 13.5 usec per loop $ python -m timeit -n 100000 -r 3 'for i in xrange(1,100): i*i' 100000 loops, best of 3: 14.7 usec per loop
	Ответить | Правка | К родителю #359 | Наверх | Cообщить модератору

	319. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от ivan (??), 11-Янв-14, 15:56
	>>> - python 2 почти идеален :) Откройте для себя [например] GIL!
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	320. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 11-Янв-14, 16:35
	>>>> - python 2 почти идеален :) > Откройте для себя [например] GIL! Еще одно троллоло вернулось с каникул?
	Ответить | Правка | Наверх | Cообщить модератору

3. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+9 +/–
Сообщение от Аноним (-), 31-Дек-13, 11:04
Не знаю про 2%, у нас уже года два всё делается исключительно на третьей ветке. Новая версия получилась сильно лучше, это видно невооружённым глазом. Вообще качество кода и библиотек питона, то как тщательно они подходят к разработке вызывает уважение, ни в одном свободном проекте такого нет.
Ответить | Правка | Наверх | Cообщить модератору

	46. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+2 +/–
	Сообщение от www2 (ok), 31-Дек-13, 13:40
	Синдром утёнка - он такой.
	Ответить | Правка | Наверх | Cообщить модератору

4. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+6 +/–
Сообщение от Аноним (-), 31-Дек-13, 11:07
> В качестве основной причины низких темпов перехода на Python 3 упоминается продолжение параллельного развития ветки Python 2, что привело к отсутствию стимула перехода на Python 3 А может быть все проще - ну нет в Python3 той самой killer feature, которая заставила бы отказаться от проверенного кода на python2. Зато есть много несовместимостей, которые не позволяют просто перейти на python3 без переписывания кучи работающего на python2 кода. И не нужно искать глобальный заговор разработчиков по бойкотированию "такого классного python3, такого же как python2, только теперь оранжевого в крапинку и с рюшечками, и вам придется переписать весь ваш код".
Ответить | Правка | Наверх | Cообщить модератору

	43. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–1 +/–
	Сообщение от Аноним (-), 31-Дек-13, 13:32
	> А может быть все проще - ну нет в Python3 той самой > killer feature, которая заставила бы отказаться от проверенного кода на python2. А может все еще проще и всех за@#$ло переписывать в сотый раз код на бидоне, а? Там в версии 2 то совместимость ломали между подверсиями от души. Ну а уж в 3-й версии оттянулись по полной программе, угробив совместимость на корню.
	Ответить | Правка | Наверх | Cообщить модератору

	54. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от chinarulezzz (ok), 31-Дек-13, 14:48
	обратную совместимость сохраняли. А то что новые фичи добавляли между подверсиями, то разве это не хорошо? Язык живой, язык исследуется. Появился опыт, который можно применить в лучшем проектировании 3.X. Что ты там переписывал сотый раз?
	Ответить | Правка | Наверх | Cообщить модератору

	98. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Аноним (-), 31-Дек-13, 23:11
	> обратную совместимость сохраняли. Оно и видно. То скрипт работавший на 2.4 на 2.7 хрен запустишь. Теперь вот скрипт работавший на 2.7 на 3.х не работает. Отличная совместимость, тудыть их там всех растудыть. > Что ты там переписывал сотый раз? Я, к счастью, ничего: не пользуюсь таким г-ном.
	Ответить | Правка | Наверх | Cообщить модератору

	105. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 01-Янв-14, 00:21
	>> обратную совместимость сохраняли. > Оно и видно. То скрипт работавший на 2.4 на 2.7 хрен запустишь. И причем тут совместимость?  Нужный скрипту функционал могли удалить в 2.5 или 2.6, в зависимости от того, когда было анонсировано что он устарел (см. pep 4, например). Совместимость - это ведь не об сохранении до посинения^Wбесконечности любого функционала, интерфейсов и т.п., включенного в какой-то релиз. > Отличная совместимость, тудыть их там всех растудыть. Чини голову.  Причем срочно.
	Ответить | Правка | Наверх | Cообщить модератору

	126. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Аноним (-), 01-Янв-14, 04:52
	> или 2.6, в зависимости от того, когда было анонсировано что он устарел Или уж "удалить" и "устарел", или уж "обратная совместимость", пля. Почему сорец 1989 года компилится современным gcc и работает после этого? А бидорасы полагают что ломать мне работу скриптов там и тут каждый год - это нормально и вообще так и надо? > Совместимость - это ведь не об сохранении до посинения^Wбесконечности любого > функционала, интерфейсов и т.п., включенного в какой-то релиз. Ну да, оно о резком подрывании переписывать этот кусок крапа в пятый раз подряд. Я заметил. Хипстерский подход к программированию: написать по быстрому кусок г-на и потом годами пытаться делать из него конфетку. Чего как правило не получается...
	Ответить | Правка | Наверх | Cообщить модератору

	132. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 01-Янв-14, 15:12
	>> или 2.6, в зависимости от того, когда было анонсировано что он устарел > Или уж "удалить" и "устарел", или уж "обратная совместимость", пля. И то и другое. > Почему сорец 1989 года компилится современным gcc и работает после этого? Потому что он *не* заработает.  Только если написан в соответствии с каким-то распространенным стандартом, хоть ANSI. В питон - иная практика стандартизации.  Стандартом (эталонной реализацией) является CPython конкретной версии.  Хочешь запустить совсем старый скрипт - вот собери CPython x.y и вперед.  Ничем, собственно, особенно не отличается от всяких Rubi, Perl, PHP и проч.  Разве что развитие языка куда больше формализовано (PEP и т.п.), что только плюс. > А бидорасы полагают что ломать мне работу скриптов там и тут каждый год > - это нормально и вообще так и надо? Вранье.  Major-релизы выходят не каждый год (а где-то раз в два года).  Плюс, минимум один релиз устаревание должно анонсироваться, прежде чем произойдет удаление. Голову тебе явно кто-то поломал, вот что... >> Совместимость - это ведь не об сохранении до посинения^Wбесконечности любого >> функционала, интерфейсов и т.п., включенного в какой-то релиз. > Ну да, оно о резком подрывании переписывать этот кусок крапа в пятый раз подряд. Где оно "резко"?  Только у заторможенных дебилов, не следящих за тем, что их программа 2 года срет предупреждениями.
	Ответить | Правка | Наверх | Cообщить модератору

	145. "Стратегия параллельного поддержания веток Python 2 и..."	+/–
	Сообщение от arisu (ok), 01-Янв-14, 20:19
	>> Почему сорец 1989 года компилится современным gcc и работает после этого? > Потому что он *не* заработает. вот ведь… а у меня работает. ещё в k&r стиле написаное. сыпет ворнингами, но собирается и работает. вот она, сила веры — я могу своей верой заставить gcc собирать софт! надо уже религию какую-то основывать, раз я такой чудотворец.
	Ответить | Правка | Наверх | Cообщить модератору

	148. "Стратегия параллельного поддержания веток Python 2 и..."	+/–
	Сообщение от myhand (ok), 01-Янв-14, 21:44
	>>> Почему сорец 1989 года компилится современным gcc и работает после этого? >> Потому что он *не* заработает. > вот ведь… а у меня работает. Значит - повезло.  Корректнее читать: *может не* заработать. > ещё в k&r стиле написаное. Стиль - это стиль.  К стандарту он никакого отношения не имеет.  Возможно, тебе попался обычный ANSI-исходник (C89).
	Ответить | Правка | Наверх | Cообщить модератору

	149. "Стратегия параллельного поддержания веток Python 2 и..."	+/–
	Сообщение от arisu (ok), 01-Янв-14, 21:58
	> Корректнее читать: *может не* заработать. против такой формулировки возразить не могу. >> ещё в k&r стиле написаное. > Стиль — это стиль.  К стандарту он никакого отношения не имеет. вообще-то, имеет — косвенное. использование k&r стиля явно показывает, что программа очень древняя.
	Ответить | Правка | Наверх | Cообщить модератору

	150. "Стратегия параллельного поддержания веток Python 2 и..."	+/–
	Сообщение от myhand (ok), 01-Янв-14, 22:34
	>>> ещё в k&r стиле написаное. >> Стиль — это стиль.  К стандарту он никакого отношения не имеет. > вообще-то, имеет — косвенное. использование k&r стиля явно показывает, что программа > очень древняя. Подразумеваю, что под k&r стилем значится не форматирование - а способ указания параметров функции в ее определении.  Тогда смотри: $ cat a.c #include <stdio.h> int main(argc, argv) int argc; char* argv[]; {     int c = 1;     printf("%d\n", c + argc);     return 0; } $ gcc -std=c11 a.c $ ./a.out 1 2 3 5 Конкретно это - не поломали до сих пор.
	Ответить | Правка | Наверх | Cообщить модератору

	151. "Стратегия параллельного поддержания веток Python 2 и..."	+/–
	Сообщение от arisu (ok), 01-Янв-14, 22:42
	> Подразумеваю, что под k&r стилем значится не форматирование - а способ указания > параметров функции в ее определении. и это в том числе, конечно. > Конкретно это — не поломали до сих пор. натюрлих. но уже много лет так практически никто не пишет. потому если мы видим код в k&r стиле — то можно с очень высокой вероятностью утверждать, что код весьма древний. и тем не менее — он до сих пор собирается, об чём изначально и была речь. а ещё такой код почти наверняка использует всякие open(), read(), write(), unlink() и прочие древние штуки. которые тоже всё ещё работают. и поэтому тоже код собирается, запускается и делает то, что должен. конечно, могут быть нюансы, не спорю. на крайний случай — коду надо будет подпихнуть какие-нибудь древние libc и прочая.
	Ответить | Правка | Наверх | Cообщить модератору

	189. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Аноним (-), 03-Янв-14, 08:22
	> И то и другое. ..и можно без хлеба, да? Хипстеры они такие - хотят все и сразу. На практике получается как в том мультике - "двое из ларца, одинаковы с лица". > Потому что он *не* заработает.  Только если написан в соответствии с > каким-то распространенным стандартом, хоть ANSI. И собирается, и работает. Особенно если писан не совсем ж@#$рукими програмерами. > В питон - иная практика стандартизации. Да, "а давайте все опять раздестроим, for teh greated good!!!111". > CPython x.y и вперед. Давно мечтал ощутить себя работником террариума. > Ничем, собственно, особенно не отличается от > всяких Rubi, Perl, PHP и проч. Вот только в отличие от бидона на этом редко пишут всякие околосистемные скрипты и тому подобную требуху. Если вебдванольчикам не привыкать переписывать свой крап каждый месяц, то вот остальные совершенно не разделяют энтузиазма по поводу необходимости все бросить и пойти подорваться переписывать или хотя-бы заменять код который где-то отвалился. > куда больше формализовано (PEP и т.п.), что только плюс. Я бы предпочел чтобы оно формально сыграло в ящик. Пыхописты по крайней мере не пхают свое добро как скрипты для автоматизации разных задач в системе, etc. А вот бидон в такой роли встречается. И очень не доставляет тем что код который работал годик вдруг ВНЕЗАПНО нагибается и работать перестает. Почему шеллскрипты или севые программы не приходится таким макаром фиксить, а это гомно требует к себе повышенного внимания? > Вранье.  Major-релизы выходят не каждый год (а где-то раз в два года). Ну да, гемор не раз в год а раз в два года. Такая радость! > Плюс, минимум один релиз устаревание должно анонсироваться, "Здравствуйте, уважаемые пассажиры. С вами говорит капитан воздушного судна. У нас возникла небольшая проблема - отказали все 4 двигателя". Вот как-то так эти ваши анонсы звучат. > Голову тебе явно кто-то поломал, вот что... Не, просто для меня питон не мимими, питоняшечка, как для хипстеров. А просто ЯП. Один из. От которого головняка как-то слишком много. Да и программисты на нем - такие погромисты. Пальцы гнуть умеют. А сделать ну хоть что-нибудь дельное - фигЪ. > Где оно "резко"?  Только у заторможенных дeбилов, не следящих за тем, > что их программа 2 года срет предупреждениями. А вон прога конца 80-х на сях до сих пор собирается. Два года, говорите? Лучше я побуду заторможенны чем буду каждые 2 года подрываться переписывать код т.к. очередным хипстерам шлея под хвост попала все "улучшить". Разумеется, снеся все до основания сначала.
	Ответить | Правка | К родителю #132 | Наверх | Cообщить модератору

	202. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 03-Янв-14, 12:22
	>> И то и другое. > ..и можно без хлеба, да? Хипстеры они такие - хотят все и > сразу. На практике получается как в том мультике - "двое из > ларца, одинаковы с лица". На практике получается вполне предсказуемая политика релизов и удаления старого функционала. >> Потому что он *не* заработает.  Только если написан в соответствии с >> каким-то распространенным стандартом, хоть ANSI. > И собирается, и работает. Ну, тебе повезло.  Объяснение я привел выше. >> В питон - иная практика стандартизации. > Да, "а давайте все опять раздестроим, for teh greated good!!!111". Мой дом - мои правила.  В чем, собственно, проблема?  И, в который раз уже тебя тыкают - не "все" и не "опять".  Приведи, пожалуйста, примеры "опять" (т.е. когда A меняют на B а потом сразу на C).  Хоть один. >> Ничем, собственно, особенно не отличается от >> всяких Rubi, Perl, PHP и проч. > Вот только в отличие от бидона на этом редко пишут всякие околосистемные > скрипты и тому подобную требуху. Если вебдванольчикам не привыкать переписывать свой > крап каждый месяц, то вот остальные совершенно не разделяют энтузиазма по > поводу необходимости все бросить и пойти подорваться переписывать или хотя-бы заменять > код который где-то отвалился. Слабал свой кулскриптошит - и в кусты?  А почему, собственно, развитие питона должно прогибаться под писателей всякой требухи, которые не удосуживаются поддержкой своего, пардон, говна? > Пыхописты по крайней > мере не пхают свое добро как скрипты для автоматизации разных задач > в системе, etc. А вот бидон в такой роли встречается. И > очень не доставляет тем что код который работал годик вдруг ВНЕЗАПНО > нагибается и работать перестает. Настучи еще по голове мейнтейнеров такого дистрибутива.  Уж если погромисты не озаботились поддержкой своего скриптошита, прописать грамотно зависимости (от старого питона) - прямая задача мейнтейнерам.  Автобус тоже питон взорвал? Вторую Мировую войну тоже питон начал? > Почему шеллскрипты или севые программы не приходится > таким макаром фиксить, а это гомно требует к себе повышенного внимания? Потому что приходится, если скрипты на bash.  Да даже POSIX-sh скрипты приходится исправлять - может и путь до какого-нибудь бинарника поменяться, название программы, ключи и т.п.  Теоретик, блин... >> Вранье.  Major-релизы выходят не каждый год (а где-то раз в два года). > Ну да, гемор не раз в год а раз в два года. И не раз в два года.  Два года - это минимум.  Чаще всего - анонсируют удаление на протяжении нескольких major-релизов. >> Плюс, минимум один релиз устаревание должно анонсироваться, > "Здравствуйте, уважаемые пассажиры. С вами говорит капитан воздушного судна. У нас возникла > небольшая проблема - отказали все 4 двигателя". Вот как-то так эти > ваши анонсы звучат. Если нет чувства юмора - это не лечится.  Не шути больше, ты это не умеешь и выглядишь жалко. Вот как на самом деле: Летит самолет, люди музыку слушают, спят, и проч.  А в это время в ангарах на земле: "производитель лайнера ZYX предупреждает, что через 2 года заканчивается гарантийный срок эксплуатации его двигателей, эксплуатационщикам предлагается сменить двигатели ботов ABC, DFE, [...] на модель XYZ, устанавливается так [...]".   А вот через два года случается странное: 90% авиакомпаний внимает предупреждению и меняет двигатели, а на лайнерах оставшейся части порой слышится предупреждение пилота: "Дамы и господа, у нас тут №-й двигатель загорелся.  Не волнуйтесь, скорее всего мы долетим до дома.  И ужо - тогда мы производителя лайнера попробуем засудить по самые гланды!" >> Где оно "резко"?  Только у заторможенных дeбилов, не следящих за тем, >> что их программа 2 года срет предупреждениями. > А вон прога конца 80-х на сях до сих пор собирается. Ну и что?  Тебе повезло, вот и все. > Лучше я побуду заторможенны чем буду каждые 2 года > подрываться переписывать код т.к. очередным хипстерам шлея под хвост попала все > "улучшить". Разумеется, снеся все до основания сначала. То, что ты заторможен - давно должно быть понятно любому читателю.  Хочешь и далее фантазировать себе ужасы про "снеся все до основания" - валяй. Дурак никогда ничему даже и не собирается учиться - первый признак.
	Ответить | Правка | Наверх | Cообщить модератору

	324. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Аноним (-), 12-Янв-14, 15:16
	> На практике получается вполне предсказуемая политика релизов и удаления Вот пусть хипстеры и строятся под заскоки своего гвидо, им полезно. > Ну, тебе повезло.  Объяснение я привел выше. А вот с питоном как-то обычно не везет. Вон например знакомому програмеру мозг имеют потому что он налабал скрипт на бидоне. Через годик убунтуи в новой версии выбросили бидон2. Скрипт помер. Теперь юзеры убунты периодически клюют ему мозг. > Мой дом - мои правила.  В чем, собственно, проблема?   Проблема в том что это гомно пытается соваться в мой дом, хотя я этот низкопробный крап не приглашал. Впрочем, вы больно много трындите - правила устанавливает гвидо, а вы только строитесь под них. Остальное - ваши фантазии. Вам вон даже единственно верный способ форматирования кода сверху спустили. > "опять".  Приведи, пожалуйста, примеры "опять" (т.е. когда A меняют на > B а потом сразу на C).  Хоть один. Про "все" вы сами вякнули, я вас за язык не тянул. А теперь начинаются юления. > Слабал свой кулскриптошит - и в кусты?  А почему, собственно, развитие > питона должно прогибаться под писателей всякой требухи, Потому что это то что на бидоне и пишут в основном, собственно. > которые не удосуживаются поддержкой своего, пардон, гoвна? Основная масса поделий на питоне как раз такой требухой и является. > Вторую Мировую войну тоже питон начал? Хм... японцы были заодно с гитлером. Так что как знать, как знать... > исправлять - может и путь до какого-нибудь бинарника поменяться, название > программы, ключи и т.п. Если скрипт будет написан на питоне - эта проблема никуда не денется. >  Чаще всего - анонсируют удаление на протяжении нескольких major-релизов. Или просто говорят что Принципиально Новый (tm) бидон 3 будет несовместим, for teh greater good! Вот почему например для сей так никто не делает, так что никому не приходится подрываться переписывать тонны либ? В общем хипстеры - они такие. > 2 года заканчивается гарантийный срок эксплуатации его двигателей, эксплуатационщикам > предлагается сменить двигатели ботов ABC, DFE, [...] на модель XYZ, При этом оказывается что двигатели нифига не идентичны и надо переделать половину самолета. Далее или бизнес у конторы загибается или двигатели быстренько присобачивают "по месту" с понятными результатами. Поэтому я и не собираюсь использовать софт на бидоне. > Ну и что?  Тебе повезло, вот и все. А с питоном вот как правило не везет. И да, на сях написаны тысячи библиотек. И никто не подрывался их резко переписывать по поводу выпуска новых вариантов стандарта языка почему-то. > Дурак никогда ничему даже и не собирается учиться - первый признак. Я не собираюсь переучиваться по свистку господина гвидо. Некоторая разница, знаете ли. Пусть он там своим хипстерам указывает когда и что им переписывать "for teh greater good".
	Ответить | Правка | Наверх | Cообщить модератору

	338. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 12-Янв-14, 22:08
	> А вот с питоном как-то обычно не везет. Вон например знакомому програмеру > мозг имеют потому что он налабал скрипт на бидоне. Надо было не "лабать", а писать по человечески. >> Мой дом - мои правила.  В чем, собственно, проблема? > Проблема в том что это гомно пытается соваться в мой дом, хотя > я этот низкопробный крап не приглашал. Кто конкретно "пытается совать"?  Злой Гвидо с пистолетом у твоего виска?  Какие программки ты себе установил на своем локалхосте - абсолютно твои собственные проблемы.  Ищи альтернативы на каком-то очередном православном языке, тебе ведь никто не должен, правда? >> "опять".  Приведи, пожалуйста, примеры "опять" (т.е. когда A меняют на >> B а потом сразу на C).  Хоть один. > Про "все" вы сами вякнули, я вас за язык не тянул. А > теперь начинаются юления. Вот-вот...  Цитирую тебя, анонимное школие: Да, "а давайте *все* опять раздестроим, for teh greated good!!!111". >> исправлять - может и путь до какого-нибудь бинарника поменяться, название >> программы, ключи и т.п. > Если скрипт будет написан на питоне - эта проблема никуда не денется. Только, если кроме exec() ты в python ничего не знаешь.  Python все-таки не shell - там есть иные средства для расширения возможностей языка и стандартной библиотеки. Малыш, ты их знаешь? Впрочем, видимо, пора уже вспомнить про бисер... >>  Чаще всего - анонсируют удаление на протяжении нескольких major-релизов. > Или просто говорят что Принципиально Новый (tm) бидон 3 будет несовместим, for > teh greater good! Шизик, речь шла о второй ветке. > Вот почему например для сей так никто не > делает, так что никому не приходится подрываться переписывать тонны либ? Про "сей" и сохранение совместимости - тебе уже объясняли выше.  Повторять лишний раз эти объяснения монотонно твердящему свои фантазии - считаю излишним. >> 2 года заканчивается гарантийный срок эксплуатации его двигателей, эксплуатационщикам >> предлагается сменить двигатели ботов ABC, DFE, [...] на модель XYZ, > При этом оказывается ты продолжаешь тупо переводить на язык данной аналогии свои собственные фантазии о питоне...
	Ответить | Правка | Наверх | Cообщить модератору

	224. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от netch (ok), 07-Янв-14, 14:00
	>> или 2.6, в зависимости от того, когда было анонсировано что он устарел > Или уж "удалить" и "устарел", или уж "обратная совместимость", пля. Почему сорец > 1989 года компилится современным gcc и работает после этого? Например, потому, что C к этому времени было уже 17 лет. А питон к такому же возрасту выпустил уже 3.0. Написанное для 3.0 будет работать на 3.3, не так ли? Синтаксис Си 70-х годов современные компиляторы не понимают. Например, там вместо -= надо было писать =- (если без пробела). Только в начале 80-х, перед первым ANSI стандартом, закончили массово вычищать остатки этого. > А бидорасы полагают что ломать мне работу скриптов там и тут каждый год > - это нормально и вообще так и надо? Вот точно так же плакались и сишники 20 лет назад, что им надо всё переписывать. И всё равно ещё остатки, например, K&R определений сохранялись долго (gcc на них писался ещё где-то до 2005). >> Совместимость - это ведь не об сохранении до посинения^Wбесконечности любого >> функционала, интерфейсов и т.п., включенного в какой-то релиз. > Ну да, оно о резком подрывании переписывать этот кусок крапа в пятый > раз подряд. Я заметил. Хипстерский подход к программированию: написать по быстрому > кусок г-на и потом годами пытаться делать из него конфетку. Чего > как правило не получается... Это проблема любой разработки в современном IT. Пока не пройдёт десяток лет - её не проанализируют со всех сторон,
	Ответить | Правка | К родителю #126 | Наверх | Cообщить модератору

	325. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Аноним (-), 12-Янв-14, 15:58
	> Например, потому, что C к этому времени было уже 17 лет. На  сях при этом никому не приходится подрываться переписывать софт с ножом к горлу. Кто хочет - пишет на C(++)11, флаг в руки. Но никто не заставляет резко переписать весь код с C89 на новый, более годный вариант, а то дескать через год компилер разучится C89 и вы пойдете курить бамбук с вашими либами и софтом. И пять версий компилятора для совместимости с C89 и прочими "старыми" стандартами - тоже не требуются почему-то. > А питон к такому же возрасту выпустил уже 3.0. А у сей и вовсе кипа стандартов вышла. Только выход очередного стандарта не приводил к отпадению старого кода, нужде тащить пять разных компилеров и пять разных рантаймов в систему или нужде все резко переписать за год. > Написанное для 3.0 будет работать на 3.3, не так ли? Возможно. Но если посмотреть на 2.х - это было верно не всегда. Какая там шлея этому гвидо под хвост попадет в очередной раз - пусть эти питоновые скриптокиды и проверяют. > надо было писать =- (если без пробела). Только в начале 80-х, > перед первым ANSI стандартом, закончили массово вычищать остатки этого. Тем не менее, с тех пор совместимость так по крупному никто особо не ломал и никому не требовалось резко подрываться переписывать код с какого-нибудь C89 на C99, "потому что мы через год дропнем поддержку C89 for teh greater good". > Вот точно так же плакались и сишники 20 лет назад, что им > надо всё переписывать. ИЧСХ, они более-менее сделали выводы и с тех пор ничего по крупному не ломали и более авральной переписки кода не было. А в питоне народ только на несовместимость 2.х между собой устал чертыхаться, как на тебе, 3.0, даже и не пытающийся быть совместимым. А поскольку половина кода еще и на севые модули завязано, так что давайте еще и закидоны сей приплюсуем? :). > И всё равно ещё остатки, например, K&R определений сохранялись долго (gcc на > них писался ещё где-то до 2005). И что характерно, я не могу припомнить когда gcc завернул бы меня со сборкой старого кода, "потому что C89 был бякой, так что мы решили убрать его поддержку, юзайте C11, вот вам год чтобы все переписать".Зато на питоне такое сплошь и рядом. > Это проблема любой разработки в современном IT. Пока не пройдёт десяток лет > - её не проанализируют со всех сторон, В случае питона проблема имхо в том что все сводится к желанию левой пятки одного гвидо. Ну и общая целевая аудитория. Если ЦА пинками заставляют код форматировать - с ЯП и его програмерами имхо все понятно.
	Ответить | Правка | Наверх | Cообщить модератору

	328. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от netch (ok), 12-Янв-14, 16:18
	>> Например, потому, что C к этому времени было уже 17 лет. > На  сях при этом никому не приходится подрываться переписывать софт с > ножом к горлу. Именно это и происходило до выхода C85. Новые компиляторы не поддерживают старый синтаксис - и всё, до свидания. И сейчас есть компиляторы из новых, которые те же определения в стиле K&R уже не поддерживают. Переходите, мол, не менее чем на C85 (ANSI), а лучше ещё что-то посвежее. Мы сейчас с питоном находимся в том же положении, в котором Си был в районе 90-го. > И пять версий компилятора для совместимости с C89 и прочими > "старыми" стандартами - тоже не требуются почему-то. Если Вам лично не доводилось с этим сталкиваться - Вам повезло. >> А питон к такому же возрасту выпустил уже 3.0. > А у сей и вовсе кипа стандартов вышла. Только выход очередного стандарта > не приводил к отпадению старого кода, Это неправда, см. выше и предыдущий мой постинг. Совместимость началась только в линии от C89. >> надо было писать =- (если без пробела). Только в начале 80-х, >> перед первым ANSI стандартом, закончили массово вычищать остатки этого. > Тем не менее, с тех пор совместимость так по крупному никто особо > не ломал Верно. Именно поэтому я и объясняю, что ситуация с Питоном сейчас полностью эквивалентна ситуации с Си примерно того же возраста. >> Это проблема любой разработки в современном IT. Пока не пройдёт десяток лет >> - её не проанализируют со всех сторон, > В случае питона проблема имхо в том что все сводится к желанию > левой пятки одного гвидо. Без одобрения своего комьюнити он бы не делал такое. Сколько угодно лидеров, но они могут остаться в одиночестве, если пойдут против основного вектора развития. Вот выбрать один из нескольких равновероятных - тут да, все за лидером. > Ну и общая целевая аудитория. Если ЦА пинками заставляют код форматировать - > с ЯП и его програмерами имхо все понятно. Комментарии на основе вкусовщины мне мало интересны, потому что не вижу фатальных проблем от питонового форматирования.
	Ответить | Правка | Наверх | Cообщить модератору

	341. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 12-Янв-14, 22:35
	> Верно. Именно поэтому я и объясняю, что ситуация с Питоном сейчас полностью > эквивалентна ситуации с Си примерно того же возраста. Не полностью, конечно.  Тому есть очевидные причины - C является низкоуровневым языком.  Python - нет.  Плюс к тому - это интерпретируемый язык, в отличие от. > Без одобрения своего комьюнити он бы не делал такое. Сдается мне, ваш оппонент нарисовал в своем воображении Гвидо в виде гипножабы.  Рациональных аргументов в пользу фантастических способностей левой пятки он пока не привел. Впрочем, подождем ответа о PEP.
	Ответить | Правка | Наверх | Cообщить модератору

	348. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от netch (ok), 13-Янв-14, 00:44
	>> Верно. Именно поэтому я и объясняю, что ситуация с Питоном сейчас полностью >> эквивалентна ситуации с Си примерно того же возраста. > Не полностью, конечно.  Тому есть очевидные причины - C является низкоуровневым > языком.  Python - нет.  Плюс к тому - это интерпретируемый язык, в отличие от. Да, все эти различия есть. Но я не вижу, как они могут влиять на оценку ситуации по несовместимым изменениям языка. Что в одном, что в другом случае есть грабли, которые достаточно тяжело находятся. Причём в случае Питона хотя бы 90% их выловит банальная 2to3. В случае Си замена "=-" на "-=" - не ловится при компиляции, и аналогичной тулзы просто не было. >> Без одобрения своего комьюнити он бы не делал такое. > Сдается мне, ваш оппонент нарисовал в своем воображении Гвидо в виде > гипножабы.  Рациональных аргументов в пользу фантастических способностей > левой пятки он пока не привел. > Впрочем, подождем ответа о PEP. Ok.
	Ответить | Правка | Наверх | Cообщить модератору

	351. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Аноним (-), 13-Янв-14, 04:41
	> Именно это и происходило до выхода C85. К счастью, на тот момент это волновало полутора зубров, которые видимо смогли в результате вправить мозги всем причастным. > Новые компиляторы не поддерживают старый > синтаксис - и всё, до свидания. 1) В 1985 году мир был совсем иной, компьютеры были сильно менее распостранены и икалось куда меньшему числу народа. 2) С тех пор более 20 лет все было достаточно цивильно, видимо выводы были сделаны. 3) А что, питонистам учиться на чужих ошибках - не айс, чтоли? > И сейчас есть компиляторы из новых, которые те же определения в стиле > K&R уже не поддерживают. Переходите, мол, не менее чем на C85 > (ANSI), а лучше ещё что-то посвежее. Ну уж C89 точно компилится. А программ с более древним синтаксисом мне в последние 20 лет не попадалось, а до этого я программить не умел. Но я представляю себе неудовольствие тех кому таки пришлось переписывать. С другой стороны, упомянутый синтаксис клещился с математикой над переменными. Например a=-b по логике вещей вполне может быть a = -1 * b, а со старым синтаксисом это было бы a=a-b. Настолько неоднозначный синтаксис все-таки не айс. > Мы сейчас с питоном находимся в том же положении, в котором Си > был в районе 90-го. ...потому что гвидо слишком крут, чтобы учиться на чужих ошибках? Ну да, сначала ломать совместимость в 2.х а потом в 3.х вообще все раздестроить - здорово придумано. Ну, находитесь наздоровье с вашим питоном, туда вам и дорога, значит. Если кому-то нравятся такие запрыги по граблям на регулярной основе - прыгайте наздоровье. > Если Вам лично не доводилось с этим сталкиваться - Вам повезло. Да, мне повезло, оказывается я просто не настолько древний :). > Это неправда, см. выше и предыдущий мой постинг. Совместимость началась только в > линии от C89. Смотря что понимать под совместимостью. Программу на C11 компилер C89 не сожрет. Да и наоборот иногда только с явным указанием ключей. С другой стороны - совместимостью с питоном до версий 2.4 ... 2.5 никто и не парится особо, т.к. софта на этом почти не было. Так что то что было с C85 - для питона актуально в районе ранних 2.х. А то что господин гвидо еще несколько раз на те же грабли встал, так что ему стали прямым текстом говорить что он задолбал - его дело, "у каждого придypка свои радости". > Верно. Именно поэтому я и объясняю, что ситуация с Питоном сейчас полностью > эквивалентна ситуации с Си примерно того же возраста. Кроме того что можно было бы учиться и на чужих ошибках, вообще-то. Да и компьютеры стали более популярны, так что продолбы нагибают намного больше народа чем в 1985-м. > Без одобрения своего комьюнити он бы не делал такое. Это самое комьюнити помнится заманалось и прямым текстом стало крыть что вы уже достали, дескать, совместимость крушить. > Сколько угодно лидеров, но они могут остаться в одиночестве, > если пойдут против основного вектора развития. Хипстеры любую дрянь жрут. См. успех эппла. А питон нынче - нечто типа бэйсика такого современного. С лямбдами и ООП, "потому что это круто". ЦА - хипстеры, которых можно попытаться до дешевых быдлoкодеров проапгрейдить. Синтаксис прозрачно намекает, имхо. > Вот выбрать один из нескольких равновероятных - тут да, все за лидером. Какое-то очень рафинированное представление о том что можно затолкать в хипстерские и нубские глотки. А это основная масса пользователей питона. Остальных можно просто замять количеством, если что-то не нравится. > Комментарии на основе вкусовщины мне мало интересны, потому что не вижу фатальных > проблем от питонового форматирования. "Если нечто выглядит как язык для быдлoкодеров и ведет себя как язык для быдлoкодеров, мы называем это языком для быдлoкодеров". Старинный английский принцип про собаку...
	Ответить | Правка | К родителю #328 | Наверх | Cообщить модератору

	358. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от netch (ok), 13-Янв-14, 11:02
	>> Именно это и происходило до выхода C85. > К счастью, на тот момент это волновало полутора зубров, которые видимо смогли > в результате вправить мозги всем причастным. Ну да. Всего-то полный код как минимум двух веток Unix и уже сделанные к тому времени приложения. > 3) А что, питонистам учиться на чужих ошибках - не айс, чтоли? Вот они и учатся. Один последний переход и дальше гарантируется совместимость. > Например a=-b по логике вещей вполне может быть a = -1 > * b, а со старым синтаксисом это было бы a=a-b. Настолько > неоднозначный синтаксис все-таки не айс. Ну вот потому и поменяли. >> Мы сейчас с питоном находимся в том же положении, в котором Си >> был в районе 90-го. > ...потому что гвидо слишком крут, чтобы учиться на чужих ошибках? Ну да, > сначала ломать совместимость в 2.х а потом в 3.х вообще все > раздестроить - здорово придумано. Ну, находитесь наздоровье с вашим питоном, туда > вам и дорога, значит. Если кому-то нравятся такие запрыги по граблям > на регулярной основе - прыгайте наздоровье. Польза от языка перевешивает этот вред. >> Это неправда, см. выше и предыдущий мой постинг. Совместимость началась только в >> линии от C89. > Смотря что понимать под совместимостью. Программу на C11 компилер C89 не сожрет. Ну очевидно, что снизу вверх - то есть старое не ломается. > Хипстеры любую дрянь жрут. См. успех эппла. А питон нынче - нечто > типа бэйсика такого современного. С лямбдами и ООП, "потому что это > круто". Не потому что круто, а потому, что решает свою задачу и соответственно имеет свою нишу. И не надо ругаться на бейсик. Для своего времени это был замечательный язык, а для его ниши - таким и остаётся. 99% ругани на него это повторение модной критики сначала за столпами отрасли, которые говорили вообще-то совсем о другом, а затем за модными ораторами - эпигонами, которые не поняли суть речи столпов, зато нашли козла отпущения. >> Комментарии на основе вкусовщины мне мало интересны, потому что не вижу фатальных >> проблем от питонового форматирования. > "Если нечто выглядит как язык для быдлoкодеров и ведет себя как язык > для быдлoкодеров, мы называем это языком для быдлoкодеров". Старинный английский принцип > про собаку... 1. Он вообще-то про утку (см. хотя бы почему duck typing в том же питоне), и сформулирован неким верховным судьёй США в XIX веке. 2. Язык для быдлокодеров как раз не будет иметь отступов, потому что они не умеют форматировать, и сколь-нибудь сложный код у них не заработает. Вы, вероятно, не сталкивались с творчеством оных, поэтому и несёте такое. Любой школьник, не овладевший азами профессии и кое-как сдающий лабораторки по информатике, находится на уровне быдлокодера, и у его кода нет форматирования, пока учитель не запинает. Зато учить на нём - чтобы сразу выводить людей из такого проблемного состояния и учить думать - удобнее, чем на паскалях с компанией.
	Ответить | Правка | Наверх | Cообщить модератору

	366. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 13-Янв-14, 14:46
	>> 3) А что, питонистам учиться на чужих ошибках - не айс, чтоли? > Вот они и учатся. Один последний переход и дальше гарантируется совместимость. Что будет дальше - никому неизвестно.  Совместимость гарантируется только в py3, в том смысле как она поддерживалась в py2 ветке. В общем, об обучении у С будете вещать не раньше, чем C стандарт будет охватывать сопоставимый функционал с питоновской стандартной библиотекой, а в синтаксис C будет не менее высокоуровневым, чем питон.  В другом мире, короче.
	Ответить | Правка | Наверх | Cообщить модератору

	339. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–1 +/–
	Сообщение от myhand (ok), 12-Янв-14, 22:19
	> И пять версий компилятора для совместимости с C89 и прочими > "старыми" стандартами - тоже не требуются почему-то. Так ведь и в питоне не требуются пять версий *компилятора*. > Тем не менее, с тех пор совместимость так по крупному никто особо не ломал Скажем политкорректно - ты просто "особо не в курсе".   А еще есть прикладные либы, не одной стандартной библиотекой живы люди ведь.  Ох, беда... > В случае питона проблема имхо в том что все сводится к желанию > левой пятки одного гвидо. Ты собираешься доказать это хоть как-то?  Или предлагается верить на слово? Например, ничего что большинство PEP написано вовсе не Гвидо?
	Ответить | Правка | К родителю #325 | Наверх | Cообщить модератору

	352. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Аноним (-), 13-Янв-14, 05:02
	> Так ведь и в питоне не требуются пять версий *компилятора*. Интерпретатора и рантайма. Не особо какая разница с компилятором и рантаймом. Да, вы верно заметили - питон до сих пор интерпретатор, даже без JIT, по поводу чего сам по себе дикий тоpмoз. По этому поводу потyги писать всякие научные вычисления на бидоне выглядят особо феерично - половина написания таких вычислений сводится к борьбе с искусственными трудностями. Потому что благодаря ушлепищной скорости работы kernel алгоритма критичный к скорости на питоне один фиг не напишешь. Только glue-код между быстрыми севыми либами и модулями. А вот то что у питона при этом синтаксис напрочь не сишный - форменная идиoтека, опять же. > Скажем политкорректно - ты просто "особо не в курсе".   Скажем политкорректно: у меня программы из конца 80-х собираются и работают. А бидонисты мало того что встают на всем известные грабли, так еще сделали это несколько раз, так что гвидо стали кpыть уже просто прямым текстом, информируя его что он уже дoстал. На что он помнится клялся что бидон 3 так ломать не бу, ... - впрочем радости то? Кода на бидон 3 практически нет. > А еще есть прикладные либы, И что характерно, если бидонисты подрываются переписывать с бидон2 на бидон3, то севые либы что-то никто не подрывается переписывать с C89 до C11 "потому что мы через годик совместимость дропнем". Если верить местному олдскульщику, си таки тоже на эти грабли разок встал, но это было давно и затрагивало мало народа. И было лишь 1 раз. > не одной стандартной библиотекой живы люди ведь. Да, и кстати вы не подскажете что за фигня? Когда народу надо библу - севая библа почему-то реюзабельна везде. А подeлия на питоне - только в питоновых программах. Что там у нас насчет code reuse? Не, не слышали? А, ну да, вам же доставляет делать одну и ту же работу по пять раз. >  Ох, беда... Ну уж не питонистам про это вякать - на питоне реюзабельного кода и либ которые бы пережили например переход с 2 на 3 вообще мизер. > Ты собираешься доказать это хоть как-то?  Или предлагается верить на слово? > Например, ничего что большинство PEP написано вовсе не Гвидо? Ну да, мелкие поправки - это пожалста. А судьбоносные решения - фигвам.
	Ответить | Правка | Наверх | Cообщить модератору

	365. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 13-Янв-14, 14:33
	> Не особо какая разница с компилятором и рантаймом. Разница большая.  Компилировать свой C++-shit ты можешь днями, время тут не критично. > По этому поводу потyги писать всякие научные вычисления на бидоне выглядят особо феерично > - половина написания таких вычислений сводится к борьбе с искусственными трудностями. Я не будут продолжать разговор об армянском коньяке с тем, кто его не пил... > Да, и кстати вы не подскажете что за фигня? Когда народу надо > библу - севая библа почему-то реюзабельна везде. Блин, ушлепок, ты мне надоел.  Марш в багтрекер Debian и смотри про текущие и минувшие transitions.  Большинство их связано как раз с прикладными сишными либами, несовместимых изменений - выше крыши. > Ну уж не питонистам про это вякать - на питоне реюзабельного кода > и либ которые бы пережили например переход с 2 на 3 вообще мизер. Весь scipy-стек, это как минимум.  Но как будто тебя интересуют факты... >> Ты собираешься доказать это хоть как-то?  Или предлагается верить на слово? >> Например, ничего что большинство PEP написано вовсе не Гвидо? > Ну да, мелкие поправки - это пожалста. А судьбоносные решения - фигвам. Предъявить статистику изволь, пожалуйста.
	Ответить | Правка | Наверх | Cообщить модератору

	367. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 15-Янв-14, 01:30
	>>> Ты собираешься доказать это хоть как-то?  Или предлагается верить на слово? >>> Например, ничего что большинство PEP написано вовсе не Гвидо? >> Ну да, мелкие поправки - это пожалста. А судьбоносные решения - фигвам. > Предъявить статистику изволь, пожалуйста. Видимо, наш троллюшко окончательно сменял.  Для справки, однакоже, приведу статистику. Берем PEP из релиза 3.0 (хорошие кандидаты на судьбоносность, нес-па?), http://docs.python.org/3.0/whatsnew/3.0.html: 237 - Moshe Zadka, Guido van Rossum 238 - Moshe Zadka <moshez at zadka.site.co.il>, Guido van Rossum <guido at python.org> 3138 - Atsuo Ishimoto <ishimoto--at--gembook.org> 3120 - Martin von Löwis <martin at v.loewis.de> 3131 - Martin von Löwis <martin at v.loewis.de> 3107 - Collin Winter <collinwinter at google.com>, Tony Lownds <tony at lownds.com> 3102 - Talin <talin at acm.org> 3104 - Ka-Ping Yee <ping at zesty.ca> 3132 - Georg Brandl <georg at python.org> 3109 - Collin Winter <collinwinter at google.com> 3134 - Ka-Ping Yee 3115 - Talin <talin at acm.org> 3113 - Brett Cannon <brett at python.org> 2 из 13 пока.  И то - в соавторстве. Пилим дальше, то что было портировано на py2: 343 - Guido van Rossum, Nick Coghlan 366 - Nick Coghlan <ncoghlan at gmail.com> 370 - Christian Heimes <christian at python.org> 371 - Jesse Noller <jnoller at gmail.com>, Richard Oudkerk <r.m.oudkerk at googlemail.com> 3101 - Talin <talin at acm.org> 3105 - Georg Brandl <georg at python.org> 3110 - Collin Winter <collinwinter at google.com> 3112 - Jason Orendorff <jason.orendorff at gmail.com> 3116 - Daniel Stutzbach <daniel at stutzbachenterprises.com>, Guido van Rossum <guido at python.org>, Mike Verdone <mike.verdone at gmail.com> 3118 - Travis Oliphant <oliphant at ee.byu.edu>, Carl Banks <pythondev at aerojockey.com> 3119 - Guido van Rossum <guido at python.org>, Talin <talin at acm.org> 3127 - Patrick Maupin <pmaupin at gmail.com> 3129 - Collin Winter <collinwinter at google.com> 3141 - Jeffrey Yasskin <jyasskin at google.com> 2 из 14.  И тоже, только в соавторстве.
	Ответить | Правка | Наверх | Cообщить модератору

	260. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Я (??), 08-Янв-14, 00:16
	>> или 2.6, в зависимости от того, когда было анонсировано что он устарел > Или уж "удалить" и "устарел", или уж "обратная совместимость", пля. Почему сорец > 1989 года компилится современным gcc и работает после этого? И конечно ты этот код показать не можешь?
	Ответить | Правка | К родителю #126 | Наверх | Cообщить модератору

	326. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Аноним (-), 12-Янв-14, 16:01
	> И конечно ты этот код показать не можешь? Да фигня вопрос. Спросите у гугли про LZSS, LZW, LZ77/78 - он вам такого добра выдаст навалом (цифры в названии LZ намекают что код середины-конца 80-х это чуть ли не авангардизм, ибо алгоритмы стары как мир).
	Ответить | Правка | Наверх | Cообщить модератору

	109. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–1 +/–
	Сообщение от chinarulezzz (ok), 01-Янв-14, 00:54
	>> обратную совместимость сохраняли. > Оно и видно. То скрипт работавший на 2.4 на 2.7 хрен запустишь. покажи его. > Теперь вот скрипт работавший на 2.7 на 3.х не работает. Отличная > совместимость, тудыть их там всех растудыть. 3.Х - новая версия. Мы же говорили о подверсиях. >> Что ты там переписывал сотый раз? > Я, к счастью, ничего: не пользуюсь таким г-ном. Так ты ничего не переписывал? Или переписывал?
	Ответить | Правка | К родителю #98 | Наверх | Cообщить модератору

	190. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–1 +/–
	Сообщение от Аноним (-), 03-Янв-14, 08:26
	> Так ты ничего не переписывал? Или переписывал? Я отматюкался и заменил отвалившиеся поделки на питоне на эквивалентную сишную прогу. Теперь в ближайшие 10 лет можно не париться...
	Ответить | Правка | Наверх | Cообщить модератору

	192. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–1 +/–
	Сообщение от chinarulezzz (ok), 03-Янв-14, 09:14
	> Я отматюкался и заменил отвалившиеся поделки на питоне на эквивалентную сишную прогу. > Теперь в ближайшие 10 лет можно не париться... кул стори, бро.
	Ответить | Правка | Наверх | Cообщить модератору

	161. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Michael Shigorin (ok), 02-Янв-14, 13:44
	> Язык живой, язык исследуется. Появился опыт Интересно, почему у тикля живость проявляется в противоположном -- написал десять лет тому, работает и на современных версиях?..
	Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

	170. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–1 +/–
	Сообщение от myhand (ok), 02-Янв-14, 16:17
	>> Язык живой, язык исследуется. Появился опыт > Интересно, почему у тикля живость проявляется в противоположном -- написал десять лет > тому, работает и на современных версиях?.. На вкус и цвет...  Не, это прекрасно подходит для идеального от рождения языка (а есть такие?), в котором не хочется исправить какой-то идиотизм и т.п.  (Боюсь, это все не про tcl.)  Ну или для компилируемого низкоуровневого языка, типа C (да и там, вроде, иногда ломают). В общем, не для большинства живых, развивающихся ЯП (тикль вряд-ли в эту категорию уже входит).
	Ответить | Правка | Наверх | Cообщить модератору

	182. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Michael Shigorin (ok), 03-Янв-14, 02:21
	> в котором не хочется исправить какой-то идиотизм и т.п. Вот почему-то в некоторых языках вопрос оказывается таким, а в некоторых -- нет. По мотивам Вашего с Ф.Ф. обсуждения могу отметить, что изменение _семантики_ API без смены имён -- это идиотизм в мозгах разработчиков, обычно неисправимый.  Такое же студенты учинили с пресловутым apache2 (точнее, apr) -- были секунды, стали миллисекунды, подумаешь. Т.е. когда люди и сами не пользуются, и не представляют, каково это вообще -- плодами их трудов собственно пользоваться.
	Ответить | Правка | Наверх | Cообщить модератору

	334. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от netch (ok), 12-Янв-14, 16:29
	>> в котором не хочется исправить какой-то идиотизм и т.п. > Вот почему-то в некоторых языках вопрос оказывается таким, а в некоторых -- > нет. > По мотивам Вашего с Ф.Ф. обсуждения могу отметить, что изменение _семантики_ API > без смены имён -- это идиотизм в мозгах разработчиков, обычно неисправимый. В случае py2->py3 нет проблем (только затраты) на переход поэтапно, если сделать эти самые промежуточные версии. Например, с таким планом: 2.8: выпускаем версию со штатными алиасами listkeys для keys и т.п. для dict; совместимость 2.7+2.8 - использование старых имён; за время работы с 2.8 ожидаем мягкий перевод на новые имена; 2.9: сохраняем это, но объявляем deprecated старые имена; за время работы с 2.9 ожидаем замену d.listkeys() -> list(d.keys()); 2.10: listkeys() отменяется; keys() переключается на выдачу итератора; все плавно меняют iterkeys -> keys; 2.11: алиасы типа iterkeys отменяются (где-то тут можно слиться и с 3-й веткой). Аналогично по всем остальным фичам (bytes/unicode, имена модулей, etc.) - кажется, 4 версий хватит на мягкий переход по стандартным принципам. С таким планом я лично не против поэтапной смены в том числе и со сменой семантики уже известных имён, при выполнении условия, что финальная версия будет более устойчива. Модуль six делает что-то похожее, но более топорно и дорого в рантайме. >  Такое же студенты учинили с пресловутым apache2 (точнее, apr) -- > были секунды, стали миллисекунды, подумаешь. > Т.е. когда люди и сами не пользуются, и не представляют, каково это > вообще -- плодами их трудов собственно пользоваться. При резком рывке - я согласен с тобой. При проработанном плане миграции - можно действовать по этому плану.
	Ответить | Правка | Наверх | Cообщить модератору

	343. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 12-Янв-14, 22:56
	> Аналогично по всем остальным фичам (bytes/unicode, имена модулей, etc.) - кажется, 4 > версий хватит на мягкий переход по стандартным принципам. "bytes/unicode", изменение "/" - не просто сделать именно так, плавным образом. Попробуйте разобраться с / в качестве тестового примера.  Жду предложений по плавной миграции. > С таким планом я лично не против поэтапной смены в том числе > и со сменой семантики уже известных имён, при выполнении условия, что > финальная версия будет более устойчива. Вам давно толкуют, что суть части изменений была именно в том, что постепенный переход - невозможен. > Модуль six делает что-то похожее, но более топорно и дорого в рантайме. six не обеспечивает никакой совместимости.  Это просто библиотека для облегчения миграции.
	Ответить | Правка | Наверх | Cообщить модератору

	346. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от netch (ok), 13-Янв-14, 00:38
	>> Аналогично по всем остальным фичам (bytes/unicode, имена модулей, etc.) - кажется, 4 >> версий хватит на мягкий переход по стандартным принципам. > "bytes/unicode", изменение "/" - не просто сделать именно так, плавным образом. > Попробуйте разобраться с / в качестве тестового примера.  Жду предложений по > плавной миграции. Судя по этой реплике, Вы вообще не в курсе, как до сих пор делалась миграция в питоне. Что ж, напоминаю. Она делается по тому самому "тик-так", который любит Intel: два типа действий: "тик" - один и тот же код программы, но смена версии питона, и "так" - одна и та же версия питона, но правка программы. На сейчас есть устойчивый 2.7. Представим себе, что в 2.8 деление уже сделано точь-в-точь как в 3.x, то есть '/' всегда генерирует float, а не остаток. У нас есть сейчас уже 2.7, где есть '//' (на самом деле появилось в 2.6?) Сидя на 2.7, можно исправить код с тем, что там, где деление должно быть нацело, '/' меняется на '//'. Далее переходим на 2.8, и всё работает. Некоторые места, таки да, делаются сложнее. Например, то, что b'\n'[0] == 13, а не b'\n'. Но тоже возможно. >> С таким планом я лично не против поэтапной смены в том числе >> и со сменой семантики уже известных имён, при выполнении условия, что >> финальная версия будет более устойчива. > Вам давно толкуют, что суть части изменений была именно в том, что > постепенный переход - невозможен. От того, что "давно толкуют", это не становится правдой, по крайней мере чисто для питонового кода. Переход возможен, с дополнительными "строительными лесами". Весь плач про невозможность это всего лишь нежелание напрягаться. С print_function в 2.x, например, напряглись и не плакались о тяжёлой судьбе. >> Модуль six делает что-то похожее, но более топорно и дорого в рантайме. > six не обеспечивает никакой совместимости.  Это просто библиотека для > облегчения миграции. Вот именно. А теперь попробуйте сначала конструктивно подумать, что я имел в виду (то есть самому вообразить аналогичный путь перехода, как его сделать), прежде чем отвечать.
	Ответить | Правка | Наверх | Cообщить модератору

	349. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 13-Янв-14, 01:12
	> Судя по этой реплике, Вы вообще не в курсе, как до сих > пор делалась миграция в питоне. Что ж, напоминаю. К счастью, знаю.  В частности - довожу до вашего сведения, что синтаксис, семантику покуда так не меняли. > На сейчас есть устойчивый 2.7. Представим себе, что в 2.8 деление уже > сделано точь-в-точь как в 3.x, то есть '/' всегда генерирует float, > а не остаток. У нас есть сейчас уже 2.7, где есть > '//' (на самом деле появилось в 2.6?) Сидя на 2.7, можно > исправить код с тем, что там, где деление должно быть нацело, > '/' меняется на '//'. Далее переходим на 2.8, и всё работает. Это не то как делаются несовместимые изменения в 2.x.   Вам в PEP5. Так что извольте вынуть из рукава промежуточные шаги.  Пусть старый вариант / объявлен deprecated в 2.7.  Я хочу там обещанную "warning" от парсера. То что описали вы - делает from __future__ import.  Теоретически, наверно нет ничего невозможного во введении *всех* новшеств из py3 подобным образом. А практически - они, как я понимаю разработчиков python, приведут к переусложнению  потрохов CPython. > От того, что "давно толкуют", это не становится правдой, по крайней мере > чисто для питонового кода. Переход возможен, с дополнительными "строительными лесами". > Весь плач про невозможность это всего лишь нежелание напрягаться. > С print_function в 2.x, например, напряглись и не плакались о тяжёлой судьбе. Я пока доказательства возможности не увидел и утверждения разработчиков о невозможности подобного (собственно, причина появления py3) - звучат весомей.
	Ответить | Правка | Наверх | Cообщить модератору

	360. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от netch (ok), 13-Янв-14, 11:29
	>> Судя по этой реплике, Вы вообще не в курсе, как до сих >> пор делалась миграция в питоне. Что ж, напоминаю. > К счастью, знаю.  В частности - довожу до вашего сведения, что > синтаксис, семантику покуда так не меняли. Что именно считать синтаксисом и семантикой? Например, был ряд запланированных устареваний модулей по этой схеме: http://docs.python.org/release/2.4/whatsnew/node13.html The mpz, rotor, and xreadlines modules have been removed. http://docs.python.org/release/2.5/whatsnew/modules.html "The old regex and regsub modules, which have been deprecated ever since Python 2.0, have finally been deleted. Other deleted modules: statcache, tzparse, whrandom." Если Вы считаете, что изменения в библиотеке нельзя включать в это рассмотрение, я заранее не соглашусь. >> На сейчас есть устойчивый 2.7. Представим себе, что в 2.8 деление уже >> сделано точь-в-точь как в 3.x, то есть '/' всегда генерирует float, >> а не остаток. У нас есть сейчас уже 2.7, где есть >> '//' (на самом деле появилось в 2.6?) Сидя на 2.7, можно >> исправить код с тем, что там, где деление должно быть нацело, >> '/' меняется на '//'. Далее переходим на 2.8, и всё работает. > Это не то как делаются несовместимые изменения в 2.x.   Вам > в PEP5. Я и не собираюсь это делать, потому что данное изменение относится к миграции на 3.x, а не сохранения стиля 2.x. Все предложенные алгоритмы перехода - именно для этого случая. > Так что извольте вынуть из рукава промежуточные шаги.  Пусть старый > вариант / объявлен deprecated в 2.7.  Я хочу там обещанную "warning" > от парсера. Я вам её не обещал, точно так же как в процессе перехода на 3.x все эти обещания PEP 5 были похерены. Так что обвинять *меня* в создании проблемах перехода на 3.x, мягко говоря, некорректно. Но если Вы действительно хотите это сделать - путь тоже есть: * вводим новую функцию типа divide() * вводим во __future__ новый импорт, который генерирует жалобы на все непеределанные '/' в тексте; должно быть или '//' или 'divide()' * на следующих версиях восстанавливаем рекомендацию использовать '/' и депрекейтим divide(). Это и есть те "строительные леса" на время перехода, о которых я говорил. Да, громоздко. Да, лишняя работа. Зато обеспечивает плавный переход и тестирование с соблюдением остальных требований PEP5 или хотя бы их духа. > То что описали вы - делает from __future__ import.  Теоретически, наверно > нет ничего невозможного во введении *всех* новшеств из py3 подобным образом. > А практически - они, как я понимаю разработчиков python, приведут к > переусложнению  потрохов CPython. Только на время перехода и достаточно немного - десяток лишних методов и функций. >> От того, что "давно толкуют", это не становится правдой, по крайней мере >> чисто для питонового кода. Переход возможен, с дополнительными "строительными лесами". >> Весь плач про невозможность это всего лишь нежелание напрягаться. >> С print_function в 2.x, например, напряглись и не плакались о тяжёлой судьбе. > Я пока доказательства возможности не увидел и утверждения разработчиков > о невозможности подобного (собственно, причина появления py3) - звучат весомей. Сочувствую, если для Вас они звучат весомей, не смотря на открытые факты.
	Ответить | Правка | Наверх | Cообщить модератору

	362. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 13-Янв-14, 14:00
	> Что именно считать синтаксисом и семантикой? Синтаксис и семантику.  Например, изменение смысла оператора / для тех же самых типов аргументов (int).  Или вот изменение синтаксиса print. > Например, был ряд запланированных устареваний > модулей по этой схеме: Язык никак не поменялся. > Я и не собираюсь это делать, потому что данное изменение относится к > миграции на 3.x, а не сохранения стиля 2.x. Я не знаю другого руководства для введения несовместимых изменений плавным образом. > Но если Вы действительно хотите это сделать - путь тоже есть: > * вводим новую функцию типа divide() > * вводим во __future__ новый импорт, который генерирует жалобы на все непеределанные > '/' в тексте; должно быть или '//' или 'divide()' Никаких __future__.  Просто выходит новый релиз - и генерит предупреждения на использование / > * на следующих версиях восстанавливаем рекомендацию использовать '/' и депрекейтим divide(). В следующих версиях мы сперва удаляем /, затем только вводим / заново и депрекейтим divide. > Это и есть те "строительные леса" на время перехода, о которых я > говорил. Да, громоздко. Да, лишняя работа. Угу.  После такого безумства - считаем оставшихся пользователей по пальцам одной руки... Вдумайтесь: чтобы заменить "богомерзкий" синтаксис или семантику (на что-то несовместимое) - вы предлагаете какую-то часть синтаксиса языка выпилить *целиком*.  И после того как пользователи смигрировали свой код на что-то эквивалентное - восстановить старый синтаксис с нужным "патчем".  И заставить пользователей делать изменения еще раз, выпилив эквивалент... Ничего удивительного, что разработчики Python предпочли иной вариант.  Кстати, было бы любопытным понаблюдать ваш сценарий в действии на примере другого языка.  Было такое? >> То что описали вы - делает from __future__ import.  Теоретически, наверно >> нет ничего невозможного во введении *всех* новшеств из py3 подобным образом. >> А практически - они, как я понимаю разработчиков python, приведут к >> переусложнению  потрохов CPython. > Только на время перехода и достаточно немного - десяток лишних методов и функций. Доказательством этого будет полный набор нововведений из py3 в __future__.  А пока, извините, не верю.
	Ответить | Правка | Наверх | Cообщить модератору

	353. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Аноним (-), 13-Янв-14, 05:05
	> В случае py2->py3 нет проблем (только затраты) на переход поэтапно, Щаззззз. В убунте например вынесли питон2 из дефолтной поставки и программерам теперь клюют мозг - "ваше подeлие у нас не запускается". Так что половина народа осталось без привычных скриптов а програмеры на этом вынуждены резко и внепланово вкалывать, переписывая код.
	Ответить | Правка | К родителю #334 | Наверх | Cообщить модератору

	357. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от netch (ok), 13-Янв-14, 10:45
	>> В случае py2->py3 нет проблем (только затраты) на переход поэтапно, > Щаззззз. В убунте например вынесли питон2 из дефолтной поставки и программерам теперь > клюют мозг - "ваше подeлие у нас не запускается". Так что > половина народа осталось без привычных скриптов а програмеры на этом вынуждены > резко и внепланово вкалывать, переписывая код. Я им сочувствую. Но Вы перепутали контекст и модальность разговора, и Ваш ответ никак не связан с обсуждаемой тематикой.
	Ответить | Правка | Наверх | Cообщить модератору

	345. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 12-Янв-14, 23:57
	>> в котором не хочется исправить какой-то идиотизм и т.п. > Вот почему-то в некоторых языках вопрос оказывается таким, а в некоторых -- нет. Те, в которых "нет" - умирают, или еще не достигли сопоставимого с Python возраста. Вы можете привести контрпример высокоуровневого языка c "другим вопросом" (ц)? > По мотивам Вашего с Ф.Ф. обсуждения могу отметить, что изменение _семантики_ API > без смены имён -- это идиотизм в мозгах разработчиков, обычно неисправимый. Вы про многострадальные строки, или я уже запамятовал какой пример там приводился?  Так подобное изменение невозможно было бы провести без изменения "семантики".  Совсем простой пример - оператор /.  Для подобного и была ветка 3.x.  Это новый язык. Надеюсь, вы не утверждаете что дизайнеры языков не пука^Wсовершают ошибок?  Вполне логично эти их рано или поздно исправлять - и не ценой бесконечного усложнения интерпретатора и плясок в нем с бубнами вокруг старого синтаксиса, гадания "какова стандарту мне скрипт подсунули" и проч.  Собирать gcc какой-то античный хлам вы можете хоть день - время компиляции никого, кроме гентоводов не волнует.  А тут надо бистро-бистро.
	Ответить | Правка | К родителю #182 | Наверх | Cообщить модератору

	171. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–1 +/–
	Сообщение от chinarulezzz (ok), 02-Янв-14, 16:22
	>> Язык живой, язык исследуется. Появился опыт > Интересно, почему у тикля живость проявляется в противоположном -- написал десять лет > тому, работает и на современных версиях?.. Хороший язык, много написал на нём. Треды появились в 8.6, в 2012 году. Документация по ним - оставляет желать лучшего. Пришлось писать на перле, где имхо лучшая реализация/документация. P.S. Питон тоже обратно совместим, кроме 2.x/3.x. Мне кажется, это из за ООП и рефакторинга, который постоянно сопутствует разработке и влияет на неё, "заставляя" разработчиков оптимизировать, искать узкие места в языке, делать его еще прозрачней, понятней, для сопровождения, и проще, в том числе с целью облегчить читаемость, ну и т.д. Вообще, могу ошибаться. Быдлокодер'c...
	Ответить | Правка | К родителю #161 | Наверх | Cообщить модератору

	173. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 02-Янв-14, 16:47
	> P.S. Питон тоже обратно совместим, кроме 2.x/3.x. Нет, конечно.  В том смысле как заявляет Миша (10 лет без поломок обратной совместимости!).  Но, как минимум, должен выйти один мажорный релиз, в котором "фича" помечается как устаревшая, прежде чем ее удалят.
	Ответить | Правка | Наверх | Cообщить модератору

	181. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Michael Shigorin (ok), 03-Янв-14, 02:16
	> Нет, конечно.  В том смысле как заявляет Миша (10 лет без > поломок обратной совместимости!). Поправочка: это не заявление, а неплохой пример.
	Ответить | Правка | Наверх | Cообщить модератору

	193. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–1 +/–
	Сообщение от chinarulezzz (ok), 03-Янв-14, 09:16
	>> Нет, конечно.  В том смысле как заявляет Миша (10 лет без >> поломок обратной совместимости!). > Поправочка: это не заявление, а неплохой пример. этот пример не идёт в ногу со временем. Равняться на такие примеры где-то стоит, где-то нет.
	Ответить | Правка | Наверх | Cообщить модератору

	225. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от netch (ok), 07-Янв-14, 14:09
	>> Язык живой, язык исследуется. Появился опыт > Интересно, почему у тикля живость проявляется в противоположном -- написал десять лет > тому, работает и на современных версиях?.. Это интересно, но вместе с ценностью самого тикля. Что-то на практике она оказалась практически нулевой.
	Ответить | Правка | К родителю #161 | Наверх | Cообщить модератору

	254. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Я (??), 07-Янв-14, 23:50
	>Интересно, почему у тикля живость проявляется в противоположном -- написал десять лет тому, работает и на современных версиях?.. Наверное потому, что он еле живой.
	Ответить | Правка | К родителю #161 | Наверх | Cообщить модератору

	95. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+1 +/–
	Сообщение от Мяут (ok), 31-Дек-13, 22:52
	В новости и об этом сказано: > В качестве второй причины называется отсутствие у разработчиков интереса к ветке Python 3, которая не содержала кардинальных прорывных улучшений, которые могли бы подтолкнуть людей к внедрению новой ветки.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

7. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+2 +/–
Сообщение от QuAzI (ok), 31-Дек-13, 11:16
Чувак обиделся что народ о бэк компатибилити думает больше чем о гонке за цифрами?
Ответить | Правка | Наверх | Cообщить модератору

	29. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Аноним (-), 31-Дек-13, 12:38
	Чувак надеялся когда-нибудь выкинуть питон 2 на помойку, но этот день все не приходит. Его не сильно прикалывает поддерживать 2 ветки одновременно. Объявил бы, что 2.8 будет последней и не рыба ни мясо, все бы и подумали, что лучше сразу перейти на питон 3 чем на непонятно что.
	Ответить | Правка | Наверх | Cообщить модератору

	32. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+3 +/–
	Сообщение от dxd (?), 31-Дек-13, 12:52
	Дык уже давно объявили что 2.8 вообще не будет.
	Ответить | Правка | Наверх | Cообщить модератору

12. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+2 +/–
Сообщение от B7W (?), 31-Дек-13, 11:29
Вот засранец, сами 5 лет ждали что бы добавить поддержку в один из ключевых проектов (Django). А теперь говорят мол чего все не переехали. Интересно услышать сколько в PPI мертвых пакетов, а уже потом говорить о количестве с python 3.
Ответить | Правка | Наверх | Cообщить модератору

17. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+3 +/–
Сообщение от web (?), 31-Дек-13, 11:39
> Например, в каталоге Python Package Index (https://pypi.python.org/pypi) с Python 3 связано > всего 2% загрузок пакетов. Более того, почти не создано кода, работающего > только с Python 3. Мэйнтейнер Pypi, Donald Stufft, отключил счетчик загрузок уже довольно таки давно о каких процентах загрузок идет речь? Классификаторы проставляемые вручную, не всегда показывают что пакет имеет поддержку Python3. FYI: https://mail.python.org/pipermail/distutils-sig/2013-May/020...
Ответить | Правка | Наверх | Cообщить модератору

	44. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–1 +/–
	Сообщение от Аноним (-), 31-Дек-13, 13:33
	> Мэйнтейнер Pypi, Donald Stufft, отключил счетчик загрузок уже довольно таки давно Что, стыдно стало за нафигнужность? :)
	Ответить | Правка | Наверх | Cообщить модератору

	50. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+1 +/–
	Сообщение от web (?), 31-Дек-13, 14:23
	ссылку для кого оставил?! в ней всё расписано: There are numerous reasons for their removal/deprecation some of which are:     - Technically hard to make work with the new CDN         - The CDN is being donated to the PSF, and the donated tier does not offer any form of log access         - The work around for not having log access would greatly reduce the utility of the CDN     - Highly inaccurate         - A number of things prevent the download counts from being inaccurate, some of which include:             - pip download cache             - Internal or unofficial mirrors             - Packages not hosted on PyPI (for comparisons sake)             - Mirrors or unofficial grab scripts causing inflated counts (Last I looked 25% of the downloads were from a known mirroring script).     - Not particularly useful         - Just because a project has been downloaded a lot doesn't mean it's good         - Similarly just because a project hasn't been downloaded a lot doesn't mean it's bad
	Ответить | Правка | Наверх | Cообщить модератору

	99. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–1 +/–
	Сообщение от Аноним (-), 31-Дек-13, 23:12
	> being donated to the PSF, and the donated tier does not > offer any form of log access Люблю бидонистов. Им сложно обработать нажатие кнопки. Чтение логов сервера для них - неподъемная задача. И вот такая дребедень - каждый день, каждый день. Инвалиды от мира программирования.
	Ответить | Правка | Наверх | Cообщить модератору

	104. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 01-Янв-14, 00:10
	>> being donated to the PSF, and the donated tier does not >> offer any form of log access > Люблю бидонистов. Им сложно обработать нажатие кнопки. Чтение логов сервера для них > - неподъемная задача. Какое нажатие кнопки способно включить чтение логов, доступа к которым их CDN-провайдер не предоставляет? > Инвалиды от мира программирования. Угу, как ты.  А может просто по агглицки читать не умеет.
	Ответить | Правка | Наверх | Cообщить модератору

	131. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–1 +/–
	Сообщение от Аноним (-), 01-Янв-14, 15:09
	> не предоставляет? Вот такой вот детский садик. Провайдер им логи не предоставляет. Серьезный проект, мля, уровня хоумпаги Васи Пупкина.
	Ответить | Правка | Наверх | Cообщить модератору

	136. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–2 +/–
	Сообщение от myhand (ok), 01-Янв-14, 15:36
	>> не предоставляет? > Вот такой вот детский садик. Провайдер им логи не предоставляет. Дурилка, ты о CDN судишь по своему локалхосту с апачем? :)
	Ответить | Правка | Наверх | Cообщить модератору

	191. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Аноним (-), 03-Янв-14, 08:34
	> Дурилка, ты о CDN судишь по своему локалхосту с апачем? :) Я сужу о вещах по тому что наблюдается. Если кто не имеет доступа к логам - он таки инвалид.
	Ответить | Правка | Наверх | Cообщить модератору

	201. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–1 +/–
	Сообщение от myhand (ok), 03-Янв-14, 11:24
	>> Дурилка, ты о CDN судишь по своему локалхосту с апачем? :) > Я сужу о вещах по тому что наблюдается. Так и запишем, о CDN ты не знаешь ничего. > Если кто не имеет доступа к логам - он таки инвалид. На каждом втором виртуальном хостинге - нет доступа к access.log, не предоставляет доступа хостер.  Все пользователи таких хостингов - инвалиды, кроме тебя, с твоим локалхостом?
	Ответить | Правка | Наверх | Cообщить модератору

	204. "Стратегия параллельного поддержания веток Python 2 и..."	+/–
	Сообщение от arisu (ok), 03-Янв-14, 12:38
	> На каждом втором виртуальном хостинге - нет доступа к access.log, не предоставляет > доступа хостер.  Все пользователи таких хостингов — инвалиды таки да.
	Ответить | Правка | Наверх | Cообщить модератору

	207. "Стратегия параллельного поддержания веток Python 2 и..."	+/–
	Сообщение от myhand (ok), 03-Янв-14, 14:05
	>> На каждом втором виртуальном хостинге - нет доступа к access.log, не предоставляет >> доступа хостер.  Все пользователи таких хостингов — инвалиды > таки да. А может просто денюшку экономят, не хочут платить за ненужную фигню?
	Ответить | Правка | Наверх | Cообщить модератору

	211. "Стратегия параллельного поддержания веток Python 2 и..."	+/–
	Сообщение от arisu (ok), 03-Янв-14, 15:29
	> А может просто денюшку экономят, не хочут платить за ненужную фигню? — а он жадный, как все чатлане: «на два чатла дешевле!»
	Ответить | Правка | Наверх | Cообщить модератору

	331. "Стратегия параллельного поддержания веток Python 2 и..."	+/–
	Сообщение от Аноним (-), 12-Янв-14, 16:22
	> А может просто денюшку экономят, не хочут платить за ненужную фигню? Так я и говорю - если вам ноги отпилить - можно на материале для двери сэкономить. Делать двери метр-пятьдеся, ну и нормальненько.
	Ответить | Правка | К родителю #207 | Наверх | Cообщить модератору

	333. "Стратегия параллельного поддержания веток Python 2 и..."	+/–
	Сообщение от arisu (ok), 12-Янв-14, 16:25
	это экономия на подушках безопасности: «но ведь я же вожу аккуратно и никуда не врежусь!»
	Ответить | Правка | Наверх | Cообщить модератору

	327. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Аноним (-), 12-Янв-14, 16:04
	> Так и запишем, о CDN ты не знаешь ничего. Я знаю о CDN поболее вашего. > На каждом втором виртуальном хостинге - нет доступа к access.log, Если вы не контролируете ваше программное окружение - вы таки инвалид. > Все пользователи таких хостингов - инвалиды, А как же.
	Ответить | Правка | К родителю #201 | Наверх | Cообщить модератору

	340. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–1 +/–
	Сообщение от myhand (ok), 12-Янв-14, 22:29
	>> Так и запишем, о CDN ты не знаешь ничего. > Я знаю о CDN поболее вашего. Молодец, хорошо что ты веришь в свои знания.  Осталось их проверить простым тестом. Попробуй объяснить, почему провайдер CDN может не предоставлять клиентам доступа к access.log'ам.  Какие технические трудности ты видишь? >> На каждом втором виртуальном хостинге - нет доступа к access.log, > Если вы не контролируете ваше программное окружение - вы таки инвалид. Смелое заявление о клиентах виртуального хостинга.  Локалхост-админа с арчем/слакой (угадал? :) далеко видать по светящимся в темноте прыщам...
	Ответить | Правка | Наверх | Cообщить модератору

	354. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Аноним (-), 13-Янв-14, 05:12
	> Попробуй объяснить, почему провайдер CDN может не предоставлять > клиентам доступа к access.log'ам.  Какие технические трудности ты видишь? Простые: это распределенная структура. Сборка логов потребует достаточно отдельных приседаний. Так что если вы не собственник этой штуки, а всего лишь сpaный арендатор - черта с два кто будет ради вас так заморачиваться. Это не отменяет того факта что вы - сpaный арендатор, на птичьих правах. Который нифига не контролирует свое окружение. И вообще, арендатор получит пендаля под зад в два счета, если собственнику этой конструкции что-либо не понравится. > Смелое заявление о клиентах виртуального хостинга.   Да обычное. Тот факт что в макдональдсе жрет больше народа чем в дорогом ресторане - совершенно не доказывает что в макдональдсе еда лучше. > Локалхост-админа с арчем/слакой (угадал? :) Вообще ни в зуб ногой. Я предпочитаю дебиан/убунту. Хотя накрайняк и редхатом могу рулить, но yum там все-таки крайне мерзостная штука и я за это RH-based не люблю. > далеко видать по светящимся в темноте прыщам... Да вы, батенька, мутант?!
	Ответить | Правка | Наверх | Cообщить модератору

	364. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 13-Янв-14, 14:21
	>> Попробуй объяснить, почему провайдер CDN может не предоставлять >> клиентам доступа к access.log'ам.  Какие технические трудности ты видишь? > Простые: это распределенная структура. Сборка логов потребует достаточно отдельных приседаний. Я бы хотел конкретного описания проблемы на техническом языке.  Пока уж выглядит чересчур расплывчато и обще.  Так что незачет. > Так что если вы не собственник этой штуки, а всего лишь > сpaный арендатор - черта с два кто будет ради вас так заморачиваться. Арендатор - это клиент.  Клиент платит вам денюшку.  Если ты не учитываешь потребности клиента и вообще плюешь на них - денюшка обтекает тебя стороной. Я доступно объясняю? >> Смелое заявление о клиентах виртуального хостинга. > Да обычное. Тот факт что в макдональдсе жрет больше народа чем в > дорогом ресторане А зачем сравнивать с дорогим рестораном?  Твой локалхост - это аналог чебуречной.  Собачек вкуснее кушать, дорогой друк? >> Локалхост-админа с арчем/слакой (угадал? :) > Вообще ни в зуб ногой. Я предпочитаю дебиан/убунту. Да, бубунту я забыл добавить...
	Ответить | Правка | Наверх | Cообщить модератору

20. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+7 +/–
Сообщение от web (?), 31-Дек-13, 11:59
вместо тысячи слов: http://alexgaynor.net/about/ "Hi, you've reached the personal web page of Alex Gaynor. I'm a 20 year old college student.."
Ответить | Правка | Наверх | Cообщить модератору

	23. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–1 +/–
	Сообщение от Аноним (-), 31-Дек-13, 12:04
	Да, действительно совсем другое восприятие новости, его фотку надо вывести в новость.
	Ответить | Правка | Наверх | Cообщить модератору

	34. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+3 +/–
	Сообщение от Аноним (-), 31-Дек-13, 12:58
	А вас не смущает, что мэйнтейнером ветки 2.4 ядра Linux был 18-летний студент ?
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	45. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Аноним (-), 31-Дек-13, 13:34
	> А вас не смущает, что мэйнтейнером ветки 2.4 ядра Linux был 18-летний студент ? Нас не смущает - мы давно забыли о 2.4. В отличие от этой груды школия тут нормальный руководитель есть. Который может нормально все обтяпать.
	Ответить | Правка | Наверх | Cообщить модератору

	80. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от ваноним (?), 31-Дек-13, 18:57
	мэйнтейнером ветки в 18-20 лет быть можно. но, среднестатистически, опыта у него будет в разы меньше, чем у, скажем, 30-летнего -- подобные суждения о жизненных циклах крупных проектов вызывают улыбку.
	Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

	137. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+1 +/–
	Сообщение от Reinar (ok), 01-Янв-14, 15:49
	> подобные суждения о жизненных циклах крупных проектов вызывают улыбку. Но почему-то суждения анонимных аналитиков на эту тему никого не смущают
	Ответить | Правка | Наверх | Cообщить модератору

	177. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–1 +/–
	Сообщение от chinarulezzz (ok), 02-Янв-14, 18:55
	>> подобные суждения о жизненных циклах крупных проектов вызывают улыбку. > Но почему-то суждения анонимных аналитиков на эту тему никого не смущают не в бровь, а в глаз xD
	Ответить | Правка | Наверх | Cообщить модератору

	61. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Аноним (-), 31-Дек-13, 15:28
	Что Вы этим хотели сказать-то?
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

21. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–3 +/–
Сообщение от all_glory_to_the_hypnotoad (ok), 31-Дек-13, 12:02
нужно всего лишь прекратить поддерживать ветку 2.х и повесить задачи багфиксов и бэкпортирования секьюрити фиксов на плечи рук утопающих.
Ответить | Правка | Наверх | Cообщить модератору

22. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–2 +/–
Сообщение от Аноним (-), 31-Дек-13, 12:03
Нас устраивает питон 2. От бобра добра не ищут.
Ответить | Правка | Наверх | Cообщить модератору

36. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–5 +/–
Сообщение от ADMIN (?), 31-Дек-13, 13:10
Python 3 слишком тормозит
Ответить | Правка | Наверх | Cообщить модератору

42. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–2 +/–
Сообщение от Аноним (-), 31-Дек-13, 13:31
удачно просидеть на 2 ветке еще лет 5, а руби пока будет развиваться
Ответить | Правка | Наверх | Cообщить модератору

	47. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от www2 (ok), 31-Дек-13, 13:44
	Удачно развиваться и развлекаться. А мы продолжим "некромансию" с Perl'ом, иронично поглядывая на выскочек :)
	Ответить | Правка | Наверх | Cообщить модератору

	74. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+4 +/–
	Сообщение от all_glory_to_the_hypnotoad (ok), 31-Дек-13, 18:21
	вы оба занимаетесь некромансией, только один с пожилым трупом, другой с молодым.
	Ответить | Правка | Наверх | Cообщить модератору

	119. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+1 +/–
	Сообщение от Аноним (-), 01-Янв-14, 04:19
	> вы оба занимаетесь некромансией, только один с пожилым трупом, другой с молодым. Спецы в трэде! Какие ещё виды практикуешь?
	Ответить | Правка | Наверх | Cообщить модератору

	166. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от chorny (ok), 02-Янв-14, 15:25
	Возрасты Perl'а и Python'а мало отличаются.
	Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

48. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+1 +/–
Сообщение от Петр (??), 31-Дек-13, 14:16
Так ведь естественная реакция же. Тот, кто додумался менять язык без сохранения обратной совместимости, должен был именно этого и ожидать. В нормальном мире такие процессы либо занимают десятки лет, либо новый вариант должен быть принципиально чем-то лучше старого, а Python3 слишком молод и, прямо скажем, мало чем примечателен.
Ответить | Правка | Наверх | Cообщить модератору

49. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–1 +/–
Сообщение от анонимм (?), 31-Дек-13, 14:22
из профиля этого гейнора: IT Volunteer Obama for America Сучёныш помог добить последнюю сверхдержаву.
Ответить | Правка | Наверх | Cообщить модератору

	101. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+1 +/–
	Сообщение от Аноним (-), 31-Дек-13, 23:43
	> сверхдержаву Не нужны.
	Ответить | Правка | Наверх | Cообщить модератору

51. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+1 +/–
Сообщение от Аноним (-), 31-Дек-13, 14:24
Разумное решение - если люди не пользуются 3м а до сих пор выбирают 2й то не проще ли развивать дальше 2й питон + бэкпортировать полезные вещи из 3-го. Могу сказать даже больше - тоже нужно было сделать с Гномом!!! Вместо перехода на 3-й просто развивать дальше второй.
Ответить | Правка | Наверх | Cообщить модератору

52. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
Сообщение от Аноним (-), 31-Дек-13, 14:30
Честно говоря читая новость я подумал, что они перестанут разрабатывать вторую ветку и будут поддерживать только 3-ю. Молодцы однако мыслят не прямолинейно.
Ответить | Правка | Наверх | Cообщить модератору

53. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+1 +/–
Сообщение от Аноним (-), 31-Дек-13, 14:47
Интересно, а если Перл 6 выйдет, с ним будет так же?
Ответить | Правка | Наверх | Cообщить модератору

58. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
Сообщение от slowpoke (?), 31-Дек-13, 15:08
а что вы на нем пишите?
Ответить | Правка | Наверх | Cообщить модератору

59. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–1 +/–
Сообщение от Нанобот (ok), 31-Дек-13, 15:15
>Стратегия параллельного поддержания веток Python 2 и Python 3 оказалась ошибочной согласен, достаточно было поддерживать одну версию, Python 2
Ответить | Правка | Наверх | Cообщить модератору

	72. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Xasd (ok), 31-Дек-13, 17:45
	>>Стратегия параллельного поддержания веток Python 2 и Python 3 оказалась ошибочной > согласен, достаточно было поддерживать одну версию, Python 2 даже не представляю как можно было бы поддержать Python-2.X до такого состояния, чтобы следующий пример кода (он для Python-3.X) не выглядел бы для Python-2.X сверх-костыльно: # -*- mode: python; coding: utf-8 -*- import sys if __name__ == '__main__':     arg1 = sys.argv[1]          assert not isinstance(arg1, bytes), 'need locale string, not bytes'          print('аргумент1: {}'.format(arg1)) # P.S.: текущая локаль в операционной системе -- может быть любая, не только UTF-8, но всё-равно аргумент нужно вывести корректно.. так-что import locale и всё такое
	Ответить | Правка | Наверх | Cообщить модератору

64. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+1 +/–
Сообщение от CPP (??), 31-Дек-13, 15:55
Надо вообще разработку 3-го прекратить и учтя полученный опыт начать пилить 4-й -) Кстати массовое не принятие новой версии языка обычное дело, например фичи с++11 уже давно были реализованы, но поголовно их не используют, хотя уже скоро выйдет c++14 а там и до c++17 не далеко.
Ответить | Правка | Наверх | Cообщить модератору

	67. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+1 +/–
	Сообщение от myhand (ok), 31-Дек-13, 16:59
	> Надо вообще разработку 3-го прекратить и учтя полученный опыт начать пилить 4-й -) И вам цифирки версий покоя не дают? > Кстати массовое не принятие новой версии языка обычное дело, например фичи с++11 > уже давно были реализованы, но поголовно их не используют Может потому, что тут есть такая вещь как компиляторы?
	Ответить | Правка | Наверх | Cообщить модератору

	69. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от slowpoke (?), 31-Дек-13, 17:13
	потому что там всякая не нужная фигня типа auto
	Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

	71. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от CPP (??), 31-Дек-13, 17:35
	Чем это auto не устраивает?
	Ответить | Правка | Наверх | Cообщить модератору

	78. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от slowpoke (?), 31-Дек-13, 18:44
	все это ломает совместимость ради 1% ленивых уродов, а значит нафиг нужно
	Ответить | Правка | Наверх | Cообщить модератору

	139. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Sauron (??), 01-Янв-14, 18:58
	Не видел ни одного живого проекта со старым вариантом использования ключевого слова auto.
	Ответить | Правка | Наверх | Cообщить модератору

	178. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Ури (?), 02-Янв-14, 22:31
	О да! Лучше писать for (std::vector<std::deque<SomeDataClass>>::iterator i = some_var.begin(); i != some_var.end(); i++) и каждый раз бегать проверять тип some_var вместо for (auto i = some_var.begin(); i != some_var.end(); i++)
	Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

	194. "Стратегия параллельного поддержания веток Python 2 и..."	+/–
	Сообщение от arisu (ok), 03-Янв-14, 10:07
	> О да! Лучше писать > for (std::vector<std::deque<SomeDataClass>>::iterator i = some_var.begin(); i != some_var.end(); > i++) и каждый раз бегать проверять тип some_var > вместо > for (auto i = some_var.begin(); i != some_var.end(); i++) смотрите, дети: это говнокодер. внимательно запоминайте и не делайте так, как он показывает. p.s. да, 'i++' в итераторе достаточно, чтобы сделать вывод, что говнокодер. но это не единственный признак, само собой.
	Ответить | Правка | Наверх | Cообщить модератору

	261. "Стратегия параллельного поддержания веток Python 2 и..."	+/–
	Сообщение от Я (??), 08-Янв-14, 00:23
	> p.s. да, 'i++' в итераторе достаточно, чтобы сделать вывод, Хранитель божественной мудрости, что же должно быть в итераторе?
	Ответить | Правка | Наверх | Cообщить модератору

	375. "Стратегия параллельного поддержания веток Python 2 и..."	+/–
	Сообщение от Гуру (?), 31-Июл-23, 00:00
	++i
	Ответить | Правка | Наверх | Cообщить модератору

	75. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok), 31-Дек-13, 18:24
	> Кстати массовое не принятие новой версии языка обычное дело, например фичи с++11 уже давно были реализованы, но поголовно их не используют не пиши о чём не знаешь. Плюсовики как никто первыми переходят на новые стандарты. Сейчас почти везде юзают c++11 и начинают с++14.
	Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

	81. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от CPP (??), 31-Дек-13, 19:21
	>> Кстати массовое не принятие новой версии языка обычное дело, например фичи с++11 уже давно были реализованы, но поголовно их не используют > не пиши о чём не знаешь. Плюсовики как никто первыми переходят на > новые стандарты. Сейчас почти везде юзают c++11 и начинают с++14. Теперь прочитай предыдущее сообщение -)
	Ответить | Правка | Наверх | Cообщить модератору

	108. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok), 01-Янв-14, 00:51
	у тебя по прежнему там написана ерунда, ничего не поменялось
	Ответить | Правка | Наверх | Cообщить модератору

	156. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Аноним (-), 02-Янв-14, 05:55
	>Плюсовики как никто первыми переходят на новые стандарты. Какая чушь. Разве что при написании лабораторных работ на 1-ом курсе.
	Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

66. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
Сообщение от myhand (ok), 31-Дек-13, 16:35
> Более того, почти не создано кода, работающего только с Python 3. Такие проекты как Django Хороша "статистика" из одного проекта.  А вот в sympy, например - общая кодовая база для py2/py3.  Поддержка же py3 хоть с помощью транслятора 2to3 - вообще давно является правилом для любого проекта. > Ни одна опрошенная крупная компания, развивающая проекты на языке Python, не использует специфичный для Python 3 код и не планирует миграцию кодовой базы на Python 3. Работает - не трогай.  Кто-б сомневался. А вот то, что они не планируют что-либо делать после завершения поддержки py2 - в это верится с трудом.  Больше верится в то, что "опрос" был из дурацки поставленных вопросов.  Ну или в раздолбайство данной выборки "companies with large Python code bases". > В частности, Python 3 не сдвинулся вперёд в таких востребованных областях, как уход от глобальной блокировки (GIL, Global Interpreter Lock) и заметное повышение производительности. Чем GIL так "востребован", его пеаром?  Какое вообще отношение должно иметь повышение производительности к синтаксису языка?  Вещи, мягко говоря, параллельные. > Вместо этого в Python 3 был расширен стандартный набор библиотек и проведена чистка проблемных мест, которые опытные разработчики уже научились обходить по привычке. Их нельзя обойти.  Можно плясать вокруг с home-made костылями.  Если поощерять это без конца - так и будут продолжать плясать... > В качестве одного из выходов из сложившегося тупика предлагается выпустить ветку Python 2.8, в которую бэкпортировать все новшества из Python 3 AFAIK, одной из основных причин появления py3 - было как раз заявление о технической невозможности такой политики релизов.
Ответить | Правка | Наверх | Cообщить модератору

	70. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Xasd (ok), 31-Дек-13, 17:33
	> Какое вообще отношение должно иметь повышение производительности к синтаксису языка? потому что python-c-api -- тоже является важной частью Python если убрать GIL -- то текущий вид python-c-api сильно поломается >> В качестве одного из выходов из сложившегося тупика предлагается выпустить ветку Python 2.8, в которую бэкпортировать все новшества из Python 3 > AFAIK, одной из основных причин появления py3 - было как раз заявление о технической невозможности такой политики релизов. помоему, создав 2.8 -- они могут похоронить 3.X . хотя тенденция перехода на 3.X вот-вот сдвинулась с места (уже, и без 2.8).. библиотеки уже как правило работают на 2.7 и 3.3 [да, используя костыли, но всё же]
	Ответить | Правка | Наверх | Cообщить модератору

	76. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 31-Дек-13, 18:35
	>> Какое вообще отношение должно иметь повышение производительности к синтаксису языка? > потому что python-c-api -- тоже является важной частью Python Я имел в виду, что производительность и синтаксис - вещи достаточно параллельные. > если убрать GIL -- то текущий вид python-c-api сильно поломается Про GIL уже написал.  Если Гвидо выпустит свой бейсик с надписью "GIL устранен, инфа 100" - вы успокоетесь?  Сомневаюсь ведь, что заметите тут разницу между враньем и правдой ;) >> AFAIK, одной из основных причин появления py3 - было как раз заявление о технической невозможности такой политики релизов. > помоему, создав 2.8 -- они могут похоронить 3.X . А по-моему - "они" не будут делать то, в чем уже расписались как в невозможном.
	Ответить | Правка | Наверх | Cообщить модератору

	133. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–1 +/–
	Сообщение от Аноним (-), 01-Янв-14, 15:14
	> потому что python-c-api -- тоже является важной частью Python Ну еще бы. Сам бидон столь тормозной что без си - никуда. Но вот два напрочь разных синтаксиса изучать - это FAIL.
	Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

	135. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–1 +/–
	Сообщение от myhand (ok), 01-Янв-14, 15:34
	>> потому что python-c-api -- тоже является важной частью Python > Ну еще бы. Сам бидон столь тормозной что без си - никуда. Казалось бы, причем тут тормоза?..  Детка, ты знал что возможность написания C-расширений есть в любом уважающем себя скриптовом ЯП, на этом самом C написанном?  Perl, Rubi... > Но вот два напрочь разных синтаксиса изучать - это FAIL. Вообще-то C никто учить не заставляет (есть и реализации Python на самом Python, даже куда более "производительные", школоте не понять...).   А если кто-то профессионально занимается программированием - синтаксисы для него вовсе не являются проблемой, малыш.  Пойми, программирование не эквивалентно синтаксису C++, как учили в твоем ПТУ.
	Ответить | Правка | Наверх | Cообщить модератору

	146. "Стратегия параллельного поддержания веток Python 2 и..."	+1 +/–
	Сообщение от arisu (ok), 01-Янв-14, 20:22
	> если кто-то профессионально занимается программированием - синтаксисы для него вовсе не > являются проблемой зато вполне являются раздражающим фактором. как бесполезные сигилы в php, например.
	Ответить | Правка | Наверх | Cообщить модератору

	179. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Ури (?), 02-Янв-14, 22:36
	> Пойми, программирование не эквивалентно синтаксису C++, как учили в твоем ПТУ. А-ха-ха-ха-ха! Битонщик пытается опустить C++сника! Ой, держите меня, я щас умру от смеха!!!
	Ответить | Правка | К родителю #135 | Наверх | Cообщить модератору

	180. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 03-Янв-14, 00:02
	>> Пойми, программирование не эквивалентно синтаксису C++, как учили в твоем ПТУ. > А-ха-ха-ха-ха! Битонщик пытается опустить C++сника! Это все что ты сподобился понять?  Видимо, вы с ним один ПТУ заканчивали(ете)...
	Ответить | Правка | Наверх | Cообщить модератору

	355. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Аноним (-), 13-Янв-14, 05:40
	> Казалось бы, причем тут тoрмoза?.. При том что это подeлие - галимый интерпретер, даже без jit, но хипстеры пытаются этот крап совать везде, от вeбни до десктопных приложений. Получается, разумеется, тормозное у...ще, что предсказуемо. >  Дeтка, ты знал что возможность написания C-расширений Вот только у си синтаксис совсем другой. Изучать два напрочь разных синтаксиса - это круто. > Вообще-то C никто учить не заставляет (есть и реализации Python на самом > Python, даже куда более "производительные", То что JIT быстрее интерпретации - я и не сомневался, только это не заслуга питона нифига. А вот то что эта хрeнь реализует урезанное множество - ликвидирует всю радость от "быстрее". > шкoлoте не понять...).   НеШкoлота (tm) совсем не комплексует по поводу свого возраста, я и вижу. > А если кто-то профессионально занимается программированием - Среди питонистов таких - полтора землекопа на всю планету. Это явно не про вас. Все чего такие как вы могут - впаривать кривой быдлoкод наиболее отборным лохам, которые потом еще и согласны за поддержку этого жуткого крапа доплачивать. Это не столько про программирование, сколько про скиллы впаривания и развода лохов. Ну в общем, нечто типа гербалайфа и наперсточников, только от IT. > синтаксисы для него вовсе не являются проблемой, малыш. Просто по моим наблюдениям большинство профессионалов уважают себя и не приветствуют идею загона пинками в стойло. Это только хипстеры так с собой обращаться позволяют. У профессионалов гордость есть, в отличие от серой биомассы быдлoкодеров. > Пойми, программирование не эквивалентно синтаксису C++, как учили в твоем ПТУ. А эти научные фантазии мы оставим на вашей совести.
	Ответить | Правка | К родителю #135 | Наверх | Cообщить модератору

	356. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от бедный буратино (ok), 13-Янв-14, 08:46
	чувак, тебе лечиться надо. во-первых, срочно, а во-вторых - серьёзно. связь с реальностью давно уже потеряна. алё! алё! мы его потеряли... снимем шляпы, господа.
	Ответить | Правка | Наверх | Cообщить модератору

	363. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 13-Янв-14, 14:12
	>>  Дeтка, ты знал что возможность написания C-расширений > Вот только у си синтаксис совсем другой. Изучать два напрочь разных синтаксиса - это круто. Не сомневаюсь, что для тебя это проблема, но это именно твоя проблема. Программирование не для тех, кто не приучился изучать новое. >> А если кто-то профессионально занимается программированием - > Среди питонистов таких - полтора землекопа на всю планету. Ну, только среди ведущих IT-компаний - таких землекопов на пару-тройку порядков больше.  У тебя есть иной критерий профессионализма? >> синтаксисы для него вовсе не являются проблемой, малыш. > Просто по моим наблюдениям большинство профессионалов уважают себя и не приветствуют идею > загона пинками в стойло. Твое "наблюдение" просто ни разу не участвовало в мало-мальски крупном проекте.  Везде приняты те или иные стандарты форматирования кода, за несоблюдение которы карают... >> Пойми, программирование не эквивалентно синтаксису C++, как учили в твоем ПТУ. > А эти научные фантазии мы оставим на вашей совести. Угадал, значит.
	Ответить | Правка | К родителю #355 | Наверх | Cообщить модератору

68. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–1 +/–
Сообщение от Xasd (ok), 31-Дек-13, 17:06
> например, выводить предупреждение при использовании str + unicode надеюсь такое предупреждение НЕльзя будет отключить.. чтобы говно`python2`кодеры познали бы уже наконец должную кару :)
Ответить | Правка | Наверх | Cообщить модератору

	73. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Sylvia (ok), 31-Дек-13, 17:58
	отключат, патчами :D в gentoo в первую очередь
	Ответить | Правка | Наверх | Cообщить модератору

	85. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+1 +/–
	Сообщение от myhand (ok), 31-Дек-13, 20:42
	И правильно сделают, ибо pep 230.
	Ответить | Правка | Наверх | Cообщить модератору

	162. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Michael Shigorin (ok), 02-Янв-14, 13:57
	>> например, выводить предупреждение при использовании str + unicode > надеюсь такое предупреждение НЕльзя будет отключить.. Вот типичная судьба таких "решений": https://build.opensuse.org/package/view_file?file=grub2-stfu...
	Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

	216. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Xasd (ok), 03-Янв-14, 19:58
	> Вот типичная судьба таких "решений": https://build.opensuse.org/package/view_file?file=grub2-stfu... да, забавно :) а почему в случае GRUB_LINUX_VID_MODE_EXTENDED закомментированым оказался grub_env_set ("gfxpayload", "text"); ?
	Ответить | Правка | Наверх | Cообщить модератору

79. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
Сообщение от Аноним (-), 31-Дек-13, 18:51
>Ни одна опрошенная крупная компания, развивающая проекты на языке Python, не использует специфичный для Python 3 код и не планирует миграцию кодовой базы на Python 3 Рождение Python 3 оказалось ошибочным. Идея сломать всё и начать заново не пользуется большой популярностью в энтерпрайзе, она вообще нигде не пользуется популярностью кроме умишек хеллоувордщиков.
Ответить | Правка | Наверх | Cообщить модератору

	84. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 31-Дек-13, 20:38
	>>Ни одна опрошенная крупная компания, развивающая проекты на языке Python, не использует специфичный для Python 3 код и не планирует миграцию кодовой базы на Python 3 > Рождение Python 3 оказалось ошибочным. Почему, о Великий Гуру? > Идея сломать всё и начать заново не > пользуется большой популярностью в энтерпрайзе В этом вашем интырпрайзе вкурсе что py3 не ломает "все"?  И что он не начинает заново это "все" обратно? Кстати, а потцему ви запрещаете нам наплювать на этот ваш интырпрайс?  Стандартные и вообще популярные библиотеки - на py3 давно портированы.  Напр., см. http://www.scipy.org/stackspec.html#stackspec http://www.scipy.org/install.html#python3 Ежели ваши анонимные индусы этого не заметили - то это проблема индусов, а не сообщества Python.
	Ответить | Правка | Наверх | Cообщить модератору

	100. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Аноним (-), 31-Дек-13, 23:15
	> В этом вашем интырпрайзе вкурсе что py3 не ломает "все"? Оно и видно. В убунте например уже вторую версию подряд апгрейдер не может даже запуститься на половине конфигураций. Что-то по части версий бидона как раз. Доходит до того что скачать апгрейдер и ВРУЧНУЮ отпедлить то что он хотел - проще чем забороть эту глючную бидонятину, которая по идее должна бы упрощать жизнь а не усложнять.
	Ответить | Правка | Наверх | Cообщить модератору

	103. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–2 +/–
	Сообщение от myhand (ok), 01-Янв-14, 00:06
	> Что-то по части версий бидона как раз. А Python-то тут причем?  С бидонами - это вы к дояркам сходите.
	Ответить | Правка | Наверх | Cообщить модератору

	134. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+1 +/–
	Сообщение от Аноним (-), 01-Янв-14, 15:15
	> А Python-то тут причем?  С бидонами - это вы к дояркам сходите. Вот я и говорю - ЯП для доярок. И софт на нем под стать.
	Ответить | Правка | Наверх | Cообщить модератору

87. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–1 +/–
Сообщение от Аноним (-), 31-Дек-13, 21:14
Немного демотивации: 1. Все девелоперы ленивы; 2. Если вы не ленивы, смотрите пункт первый.
Ответить | Правка | Наверх | Cообщить модератору

	163. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+1 +/–
	Сообщение от Michael Shigorin (ok), 02-Янв-14, 13:59
	> Немного демотивации: Кушайте сами. > 1. Все девелоперы ленивы; Нормальные -- нет.  Не путать с админами.
	Ответить | Правка | Наверх | Cообщить модератору

	164. "Стратегия параллельного поддержания веток Python 2 и..."	+/–
	Сообщение от arisu (ok), 02-Янв-14, 14:14
	>> 1. Все девелоперы ленивы; > Нормальные — нет.  Не путать с админами. ленивы, ленивы. именно поэтому они пишут софт, который будет делать за них работу. другое дело, что «чего только не сделает программист, лишь бы полезного не делать».
	Ответить | Правка | Наверх | Cообщить модератору

	330. "Стратегия параллельного поддержания веток Python 2 и..."	+/–
	Сообщение от Аноним (-), 12-Янв-14, 16:19
	> ленивы, ленивы. именно поэтому они пишут софт, который будет делать за них работу. Это далеко не единственная мотивация программистов.
	Ответить | Правка | Наверх | Cообщить модератору

	332. "Стратегия параллельного поддержания веток Python 2 и..."	+/–
	Сообщение от arisu (ok), 12-Янв-14, 16:22
	>> ленивы, ленивы. именно поэтому они пишут софт, который будет делать за них работу. > Это далеко не единственная мотивация программистов. ну да: ещё есть бабло и п^@#ли. лучше всего работает «в сочетании». а, и ещё просто любовь к мастурбации. у некоторых не проходит.
	Ответить | Правка | Наверх | Cообщить модератору

143. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+3 +/–
Сообщение от Филипп Филиппович (ok), 01-Янв-14, 19:54
Ожидаемо, в общем-то. И я очень рад, что такое мнение наконец-то звучит в PSF. С одной стороны, Python 3 как язык в целом стройнее и логичнее. Я бы ОЧЕНЬ хотел его использовать в работе, и на старте каждого питоновского проекта делаю небольшой анализ, нельзя ли его сделать на Python 3. Но поскольку обычно оказывается нужна куча сторонних библиотек, выясняется, что несколько из них всё ещё не поддерживают третью ветку. Перепиливать их самим на Python 3 невозможно (объём работ в разы превышает трудоёмкость самого проекта). И приходится благополучно продолжать жизнь на второй ветке, которая наверняка фактически будет поддерживаться ещё долго, даже если на python.org будет официально объявлено об отсутствии поддержки. Вот, по-моему, чуть-чуть бы поменьше радикализма в сломе совместимости -- и было бы всё замечательно. Не "ломай всё, раз уж всё равно решили где-то сломать", а "ломай там, где уж совсем никак, но ломай поменьше". Такой подход упростил бы портирование кода (а ведь именно в портировании кода библиотек вся проблема) в разы. Вот зачем, спрашивается, было переименовывать unicode в str, а str в новый тип? Понятно, что хотелось поддержки многоязычности по умолчанию безо всяких кодировок. Но ведь именно это сломало невероятное количество кода. А ведь вполне можно было разрулить то же самое более щадящим образом. Кому так уж мешала необходимость поставить буковку u перед константой в кавычках, если предполагается многоязычность? И ведь всё равно будет полно ситуаций, когда о понятии "кодировка" нужно помнить. Нет, поймите правильно, это всё очень красиво и логично. Но стоило ли конкретно это изменение сопряжённых с ним проблем? ИМХО, не стоило совершенно. В Python 2 кухню с кодировками нужно было понять ровно один раз, и ни для кого, кроме писателей хелловорлдов, это проблемы не составляло, а в итоге разруливанием именно этой проблемы сломано, боюсь, не менее 70% того кода, который ломается при переходе со второй ветки на третью. То есть отказавшись от одного, экстремистского по сути своей, изменения, можно было этак втрое уменьшить количество проблем портирования. А прежняя семантика оператора деления кому мешала? Что противоестественного в том, что 2/3 будет 0? Это в большинстве языков так, и ни один язык пока именно от этого не умер. Вывод: к сожалению, в Python 3 попало несколько изменений, сделанных в интересах самых малоквалифицированных пользователей ("чайников" и "хелловорлдщиков"), но при этом именно этими изменениями и была сломана большая часть совместимости кода. И эти конкретные изменения, что важно, грубо противоречат интересам тех, кто использует Python профессионально (в частности, разрабатывает и поддерживает сторонние библиотеки). Наверное, массовый переход на Python 3 состоится всё равно. Но он мог бы быть гораздо легче, если бы в чисто внешнем причёсывании языка было допущено чуть меньше радикализма. Вот вполне можно было поломать не 70% кода, а 5%, и тогда портирование было бы куда как проще. И меня удивляет, когда великодушный диктатор говорит, что GIL -- это нормально. В итоге вместо многопоточного сервера приходится писать какой-то ужас то на greenlets, то на Twisted с обязательной расшивкой обработчиков на куски сопрограмм и обёртыванием каждой длительной операции неизвестно во что, и заниматься кучей подобных, пусть иногда красивых по идеям и реализации, но лишних в контексте прикладной задачи вещей. А если бы там была полноценная многопоточность, было бы гораздо проще. Там, где нужна действительно параллельная обработка, предлагается ограничиваться техникой fork. Но это же безумие, поскольку безо всякой нужды усложняет отладку и архитектуру приложения. Иногда fork -- отличное решение, но почему это должно быть единственной возможностью? Словом, при принятии некоторых решений разработчиками языка и CPython был сделан очень странный выбор. И этот выбор уже породил проблемы. Надеюсь, всё разрешится в ближайшие несколько лет. Но большинства проблем могло бы и не быть...
Ответить | Правка | Наверх | Cообщить модератору

	147. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–1 +/–
	Сообщение от myhand (ok), 01-Янв-14, 21:40
	> Но поскольку обычно оказывается нужна куча > сторонних библиотек, выясняется, что несколько из них всё ещё не поддерживают > третью ветку. Перепиливать их самим на Python 3 невозможно 2to3 не взлетает, или просто попробовать не пытались? > Вот, по-моему, чуть-чуть бы поменьше радикализма в сломе совместимости -- и было > бы всё замечательно. Не "ломай всё, раз уж всё равно решили > где-то сломать", а "ломай там, где уж совсем никак, но ломай поменьше". Докладываю, все и не сломали.  Ваш КО. > Вот зачем, спрашивается, было переименовывать unicode в str, а str в новый тип? В смысле?  Вы вообще-то вкурсе что именно сделано? Читайте: http://docs.python.org/3.0/whatsnew/3.0.html#text-vs-data-in... > Кому так уж мешала необходимость поставить буковку u перед константой в кавычках, если > предполагается многоязычность? Сделали буковку, не переживайте (3.2?).  А до того - существовали всякие six модули... > Но стоило ли конкретно это изменение сопряжённых с ним проблем? Те изменения, на которые я указал выше - стоили. > А прежняя семантика оператора деления кому мешала? Что противоестественного в том, что > 2/3 будет 0? Это в большинстве языков так, и ни один > язык пока именно от этого не умер. Тут - да.  Ввели какой-то идиотский новый оператор еще...  Дай хомячку возможность перегружать синтаксис - он не уймется. Сделали бы рациональные числа, раз bignum уже есть. > Вывод: к сожалению, в Python 3 попало несколько изменений, сделанных в интересах > самых малоквалифицированных пользователей ("чайников" и "хелловорлдщиков"), но при этом > именно этими изменениями и была сломана большая часть совместимости кода. Однозначно, нет.  Деление было добавлено в __future__.  А большинство остальных изменений - важные и нужные вовсе не для "чайников". > И меня удивляет, когда великодушный диктатор говорит, что GIL -- это нормально. Он не просто "говорит", он объясняет почему.  Вы можете это объяснение процитировать?
	Ответить | Правка | Наверх | Cообщить модератору

	153. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Филипп Филиппович (ok), 02-Янв-14, 00:43
	>2to3 не взлетает, или просто попробовать не пытались? И чем мне это поможет портировать, скажем, gevent? Ну ладно, gevent он не чисто питоновский, хотя мне он всё равно нужен. Даже Django в те времена, когда он не поддерживал 3.0? А Twisted, который только-только начинает поддерживать? В сугубо прикладном проекте решать проблему портирования огромной (или не огромной, а просто большой) библиотеки -- не слишком ли круто? Сами разработчики зачастую не спешат портировать. И с чего бы это? Видимо, всё-таки не всё можно сделать с помощью 2to3, да и спрос на результат портирования не очень ощутим. >Он не просто "говорит", он объясняет почему.  Вы можете это объяснение процитировать? Зачем? В сегодняшних реалиях считаю объяснение отмазкой. ИМХО, если уж стали пилить новый язык (а Py3 -- именно новый) с нарушением совместимости и прочими радостями, надо было пилить то, что явно будет жать уже через несколько лет. А в тот момент всё было уже ясно. И не надо говорить, что невозможно сделать архитектуру виртуальной машины, которая будет нормально вести себя при использовании многопоточности. Это много где сделано, и зачем, спрашивается, нужно искать "свой особый путь", а не держаться мейнстрима? Когда-то существующее решение было оправданным, потом оно было имеющим право на существование, сейчас это уже просто кривизна. За эти шесть, кажется, лет, можно было бы и решить проблему радикально. И ради этой фичи портироваться бы все стали. >В смысле?  Вы вообще-то вкурсе что именно сделано? Тип str теперь значит то, что раньше значил unicode, а для того, чем раньше был str (последовательность байтов), появился новый тип. Я ровно об этом. И куча кода полетела в тартарары. >Деление было добавлено в __future__. Причём тут третья ветка? В третьей-то оно по-новому работает. Мало кто это из future включал, по правде сказать. Словом, если кратко: я всё равно считаю, что выбранное направление развития, при всей привлекательности Python 3 как языка, было во многом ошибочным. Подтверждение приведено в исходной статье. Достаточно сравнить набор библиотек для 2-й и 3-й ветки.
	Ответить | Правка | Наверх | Cообщить модератору

	154. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 02-Янв-14, 01:51
	>>2to3 не взлетает, или просто попробовать не пытались? > В сугубо прикладном проекте решать проблему портирования > огромной (или не огромной, а просто большой) библиотеки -- не слишком ли круто? Смотря что за библиотека.  Не так давно был свидетелем и активным участником перевода на py3 ряда проектов с scipy.org (раньше использовали 2to3).  Абсолютно ничего страшного. Что в вашем представлении означает "большая библиотека"? > Сами разработчики зачастую не спешат портировать. Смотря какие.  Те же проекты из scipy core - все на py3 давно работают.  Не мытьем - так катанием... >>Он не просто "говорит", он объясняет почему.  Вы можете это объяснение процитировать? > Зачем? Затем, что вы с ним не потрудились ознакомиться.  И/или - не поняли. > И не надо говорить, что невозможно сделать архитектуру виртуальной машины, которая > будет нормально вести себя при использовании многопоточности. > [...] > За эти шесть, кажется, > лет, можно было бы и решить проблему радикально. Вперед: http://www.python.org/dev/peps/pep-0001/#submitting-a-pep А то решателей - вагон, а конкретных решений так и не видно. > И ради этой фичи портироваться бы все стали. Да ну?  Ну вот мне - нафиг не упало.  Да и в рассылках проектов scipy - особых стонов по этому поводу не припомню. >>Деление было добавлено в __future__. > Причём тут третья ветка? В третьей-то оно по-новому работает. Мало кто это > из future включал, по правде сказать. Я про то, что только это, пожалуй, было в интересах "детишков".  Да и то, не факт.  Причем добавлено было в __future__ давным давно (2.5, раньше?).  Кто захотел - починил.  Не думаю, что именно это стало основной проблемой портирования. > Достаточно сравнить набор библиотек для 2-й и 3-й ветки. *Какой* набор, каких библиотек?
	Ответить | Правка | Наверх | Cообщить модератору

	165. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Филипп Филиппович (ok), 02-Янв-14, 15:02
	> Что в вашем представлении означает "большая библиотека"? Я мало привёл примеров? >Затем, что вы с ним не потрудились ознакомиться.  И/или - не поняли. Всё-таки давайте без телепатии. Я просто не нахожу эти аргументы на сегодняшний день вменяемыми. Аргументы почти всегда есть за разные точки зрения, но если результат явно идёт в противоположную от "мейнстрима" сторону, это всегда повод задуматься. Да, перепилить существующее под эффективную многопоточность было бы крайне проблематично, это не решается патчами к CPython, это серьёзный редизайн. На который, ИМХО, и стоило бы тратить прошедшие годы. Кому-то это не нужно, но есть масса областей применения, где нормальный параллелизм нужен до крайности, тот же код с большим количеством асинхронного ввода-вывода (или работы с сетью, чем я чаще всего и занимаюсь) всё-таки гораздо проще писать с полноценной многопоточностью, чем с костылями, её заменяющими. Вы знакомы с внутренним устройством сетевых библиотек (не поддержки сокетов в стандартной библиотеки, а полноценных бибилиотек ля написания сетевого кода -- Twisted, gevent)? Если да, то представьте себе, как упростилась бы их архитектура и, что ещё важнее, устройство прикладного кода под них при полноценной многопоточности и нормальных многопоточных реакторах? >*Какой* набор, каких библиотек? Из того, что нужно мне просто постоянно, это, например, gevent и Twisted. Первый отсутствует, второй только собирается.
	Ответить | Правка | Наверх | Cообщить модератору

	167. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+1 +/–
	Сообщение от myhand (ok), 02-Янв-14, 15:54
	>> Что в вашем представлении означает "большая библиотека"? > Я мало привёл примеров? Ну мне немножко лень было считать.  Ок, смотрим: http://www.ohloh.net/p/gevent -  112464 LOC http://www.ohloh.net/p/twisted -  209272 LOC vs http://www.ohloh.net/p/scipy - 656474 LOC (~25% питон) http://www.ohloh.net/p/sympy - 245255 LOC Сопоставимо все, мягко говоря, верно?  Т.е. просто кто-то сделал, а кто-то сидит и плачет... Так я вам еще докладываю, что плакали всегда.  Даже изменения в 2.x порой вынуждали переписывать старый код, от которого (см #152) бедные заказчики "довольны как слоны". >>Затем, что вы с ним не потрудились ознакомиться.  И/или - не поняли. > Всё-таки давайте без телепатии. Я просто не нахожу эти аргументы на сегодняшний > день вменяемыми. Сложно спорить с или защищать "аргументы", которые вы даже не цитируете. >>*Какой* набор, каких библиотек? > Из того, что нужно мне просто постоянно Ну так это *ваша* проблема, я не вижу в этом объективности.  То что *мне* нужно постоянно - портировано, причем давно.  Более того, я фактически уверен, что 90% существующих проектов (или сколько там мертворожденного кода?) так никогда и не портируют.  Ну и что?
	Ответить | Правка | Наверх | Cообщить модератору

	172. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Филипп Филиппович (ok), 02-Янв-14, 16:26
	Рад за вас, что для вас всё есть. Но разработка -- вещь, представьте себе, разнообразная, и не всё, что за пределами сферы ваших интересов мертво. Проекты, которые я назвал, более чем живые. Просто вас они не волнуют. Меня вот не волнуют numpy, scipy и иже с ними, так это ж не значит, что они мертворожденные, просто лично мне не нужны.
	Ответить | Правка | Наверх | Cообщить модератору

	174. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–1 +/–
	Сообщение от myhand (ok), 02-Янв-14, 17:05
	> Рад за вас, что для вас всё есть.  Но разработка -- вещь, > представьте себе, разнообразная, и не всё, что за пределами сферы ваших > интересов мертво. Я начинаю подозревать, что несмотря на ник - читать вас в школе так и не научили. Аргумент был совсем в другом.  Вы привели примеры проектов, которые не озаботились портированием.  Я привел обратные примеры.  Допускаю, что есть и то и то.  Среди "более чем жывых" проектов.  Это доказывает только то, что ничего не доказывает.  С какого боку ваша выборка более объективна чем моя? Вот если вы выделите проекты по каким-то объективным критериям (прикладная область, объем кода, популярность) и изучите какая часть там портирована - это уже будет тянуть на исследование.  А так...  Кстати, моя подборка проектов в этом смысле - объективна. "Лично мне нужно/не нужно" - не объективный критерий.
	Ответить | Правка | Наверх | Cообщить модератору

	175. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+2 +/–
	Сообщение от Филипп Филиппович (ok), 02-Янв-14, 17:43
	Вы полагаете, что я должен выдать Вам исследование? И почему это я Вам должен? То, что нужно мне (в основном одну конкретную область), я анализировал. Заметьте, я не говорю, что выборка объективна. Но в той сфере, которая нужна мне, на сегодняшний день всё не слишком хорошо, а пару лет назад было и вообще ужасно. И я ситуацией вокруг Python 3 недоволен по этой причине. И, похоже, не один я такой. Хотя рад, если Вы всем довольны, хоть один счастливый человек есть. Вот, собственно, и всё моё сообщение с самого начала, если отрезать рассуждения вокруг. Может быть, Вы всё-таки осилите его.
	Ответить | Правка | Наверх | Cообщить модератору

	176. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–2 +/–
	Сообщение от myhand (ok), 02-Янв-14, 17:55
	> Вы полагаете, что я должен выдать Вам исследование? Да не должны, конечно.  Только если претендуете на объективный анализ трудностей портирования, а не излагаете сугубо личные переживания.
	Ответить | Правка | Наверх | Cообщить модератору

	329. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+1 +/–
	Сообщение от Аноним (-), 12-Янв-14, 16:19
	> Да не должны, конечно.  Только если претендуете на объективный анализ трудностей > портирования, а не излагаете сугубо личные переживания. А по-моему это вы тут в розовых очках, пытаетесь доказать всем что ваш фетиш никаких проблем не имеет, а все кто говорит иначе - как минимум врут и клевещут.
	Ответить | Правка | Наверх | Cообщить модератору

	342. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–1 +/–
	Сообщение от myhand (ok), 12-Янв-14, 22:38
	> А по-моему это вы тут в розовых очках, пытаетесь доказать всем что > ваш фетиш никаких проблем не имеет, а все кто говорит иначе > - как минимум врут и клевещут. Вот подобное заявление - как раз прямое вранье и клевета.  Прям для палаты мер и весов.
	Ответить | Правка | Наверх | Cообщить модератору

	227. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+2 +/–
	Сообщение от netch (ok), 07-Янв-14, 14:42
	> Смотря что за библиотека.  Не так давно был свидетелем и активным > участником перевода на py3 ряда проектов с scipy.org (раньше использовали 2to3). >  Абсолютно ничего страшного. Это не показательный пример потому, что на scipy очень мало работают со строками, а там, где работают - мало проблем кодировок и т.п. А вот мой пример - работа с протоколами SIP, Radius... Они текстовые или передают много текстовых строк, а конверсия в юникод 1) нафиг не сдалась, 2) дорогая и медленная. Это значит, что мне практически во всём коде придётся текстовые константы оснастить префиксом "b". Это изменение практически всего кода, причём автоматизации через 2to3 не поддаётся, потому что эта автоматизация не предполагает автоматическую замену старого str на bytes, как должно было быть для действительно правильного исполнения. >>>Он не просто "говорит", он объясняет почему.  Вы можете это объяснение процитировать? >> Зачем? > Затем, что вы с ним не потрудились ознакомиться.  И/или - не > поняли. А, может, понял? Я, думаю, понял - с мультитредингом работаю давно. Но *поверил* ли я? Почему у JVM, .NET машины нет таких проблем и они не плачутся на то, что не могут держать один лок на всех? >> И не надо говорить, что невозможно сделать архитектуру виртуальной машины, которая >> будет нормально вести себя при использовании многопоточности. >> [...] >> За эти шесть, кажется, >> лет, можно было бы и решить проблему радикально. > Вперед: > http://www.python.org/dev/peps/pep-0001/#submitting-a-pep > А то решателей - вагон, а конкретных решений так и не видно. Ага, это уже началось стандартное "Сперва добейся". А почему мы, пользователи, должны это решать? Ну так это кончится тем, что мы потратим ресурсы - но на перевод того, что знаем и в чём разбираемся, на какую-нибудь Яву. Потому что вот в SIP я разбираюсь, и в своём продукте - да, а в потрохах Питона - нет и не вижу глубокого смысла лезть в них выполнять по факту чужую работу...
	Ответить | Правка | К родителю #154 | Наверх | Cообщить модератору

	231. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 07-Янв-14, 15:59
	>> Смотря что за библиотека.  Не так давно был свидетелем и активным >> участником перевода на py3 ряда проектов с scipy.org (раньше использовали 2to3). >>  Абсолютно ничего страшного. > Это не показательный пример потому, что на scipy очень мало работают со > строками, а там, где работают - мало проблем кодировок и т.п. Чиво?  Там дофига работы со строками.  ipython - так просто интерактивная оболочка для Python. > А вот мой пример - работа с протоколами SIP, Radius... Они текстовые > или передают много текстовых строк, а конверсия в юникод 1) нафиг > не сдалась, 2) дорогая и медленная. Это значит, что мне практически > во всём коде придётся текстовые константы оснастить префиксом "b". Это изменение > практически всего кода, причём автоматизации через 2to3 не поддаётся, потому что > эта автоматизация не предполагает автоматическую замену старого str на bytes, как > должно было быть для действительно правильного исполнения. Если эти изменения действительно масштабные - вам надо хорошо подумать головой над реорганизацией кода. >>>>Он не просто "говорит", он объясняет почему.  Вы можете это объяснение процитировать? >>> Зачем? >> Затем, что вы с ним не потрудились ознакомиться.  И/или - не >> поняли. > А, может, понял? Я, думаю, понял - с мультитредингом работаю давно. Но > *поверил* ли я? > Почему у JVM, .NET машины нет таких проблем и они не плачутся > на то, что не могут держать один лок на всех? Может потому, что эти VM купились на модное сование тредов во все дырки? >> Вперед: >> http://www.python.org/dev/peps/pep-0001/#submitting-a-pep >> А то решателей - вагон, а конкретных решений так и не видно. > Ага, это уже началось стандартное "Сперва добейся". А почему мы, пользователи, должны > это решать? Потому что вам никто ничего не должен.  Раз решений так и не появилось - это лишнее свидетельство того, как оно "надо".
	Ответить | Правка | Наверх | Cообщить модератору

	237. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от netch (ok), 07-Янв-14, 19:40
	>> Почему у JVM, .NET машины нет таких проблем и они не плачутся >> на то, что не могут держать один лок на всех? > Может потому, что эти VM купились на модное сование тредов во все > дырки? А чем плохо, что они "купились" на "модное", если у них в итоге получилось быстро и хорошо? Или Вы видите какие-то реальные скоростные преимущества в рантайме у Python перед Java? Я пока что вижу только противоположное - писать легче, да, но работает медленнее, и заметно. >>> Вперед: >>> http://www.python.org/dev/peps/pep-0001/#submitting-a-pep >>> А то решателей - вагон, а конкретных решений так и не видно. >> Ага, это уже началось стандартное "Сперва добейся". А почему мы, пользователи, должны >> это решать? > Потому что вам никто ничего не должен.  Раз решений так и > не появилось - это лишнее свидетельство того, как оно "надо". Проблема в том, что в итоге пользователи голосуют ногами, потому что альтернатива есть и её (альтернативы) провайдеры активно тянут в свою сторону. А авторы говорят на это "ну видите, никто же не сделал...", когда те, кто могли сделать - просто убежали. А так - да, никто ничего не должен. Они могли вообще забросить это и заняться подлёдной рыбалкой. Но зачем-то они стараются тянуть проект? > Чиво?  Там дофига работы со строками.  ipython - так просто > интерактивная оболочка для Python. От неё требуется скорость именно работы с текстами? А можно увидеть сравнение по скорости? > Если эти изменения действительно масштабные - вам надо хорошо подумать головой над > реорганизацией кода. Ну да, только авторы питона в белом, все остальные работать не умеют.
	Ответить | Правка | Наверх | Cообщить модератору

	241. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 07-Янв-14, 21:50
	> А чем плохо, что они "купились" на "модное", если у них в > итоге получилось быстро и хорошо? Или Вы видите какие-то реальные скоростные > преимущества в рантайме у Python перед Java? Я вижу, что несмотря на эти приемущества - python уже сейчас используют больше чем java для числодробилок.  И вряд-ли только потому, что "писать легше"... > Проблема в том, что в итоге пользователи голосуют ногами, потому что альтернатива > есть и её (альтернативы) провайдеры активно тянут в свою сторону. А > авторы говорят на это "ну видите, никто же не сделал...", когда > те, кто могли сделать - просто убежали. Может оно и так, но "убежали" - требует доказательств.  А спада популярности python не особо заметно, несмотря на засаду py2/py3, появление новых интересных языков и проч. Плюс, не все реализации python имеют GIL.  Как-то не заметно, чтобы jython/ironpython стали сильно популярными. > А так - да, никто ничего не должен. Они могли вообще забросить > это и заняться подлёдной рыбалкой. Но зачем-то они стараются тянуть проект? Делают то, что им нужно. >> Чиво?  Там дофига работы со строками.  ipython - так просто >> интерактивная оболочка для Python. > От неё требуется скорость именно работы с текстами? Скорость там в этом месте вряд-ли требуется, не для типичных случаев, как минимум.  Так и в ваших сетевых приложениях, я чай - латентность более существенна, чем ожидаемые вами проблемы от использования юникода. >> Если эти изменения действительно масштабные - вам надо хорошо подумать головой над >> реорганизацией кода. > Ну да, только авторы питона в белом Ну предложите как надо было сделать изменения работы со строками обратно совместимыми, без превращения кода в несопровождаемую капусту.  Каждый мнит себя стратегом...
	Ответить | Правка | Наверх | Cообщить модератору

	243. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от netch (ok), 07-Янв-14, 22:14
	>> А чем плохо, что они "купились" на "модное", если у них в >> итоге получилось быстро и хорошо? Или Вы видите какие-то реальные скоростные >> преимущества в рантайме у Python перед Java? > Я вижу, что несмотря на эти приемущества - python уже сейчас используют > больше чем java для числодробилок.  И вряд-ли только потому, что > "писать легше"... Если с использованием numpy и тому подобных, то используют не Питон, а его бутерброд с быстрым сишным кодом. Такое, конечно, будет быстрее чистой Явы, но считать его Питоном, мягко говоря, натянуто. >> Проблема в том, что в итоге пользователи голосуют ногами, потому что альтернатива >> есть и её (альтернативы) провайдеры активно тянут в свою сторону. А >> авторы говорят на это "ну видите, никто же не сделал...", когда >> те, кто могли сделать - просто убежали. > Может оно и так, но "убежали" - требует доказательств. Я просто видел живые примеры, но из-за их корпоративности, считаем, они все под NDA, или я не смогу внятно объяснить только на основе открытой информации. Но мотивация была именно такая: пункт 1 - "нам не нужен бутерброд, нам нужно общее средство для всего"; пункт 2 - "мы не тянем низкоуровневые средства" (обычно низкоуровневые тут это те, что не умеют GC) => "выбираем самое быстрое из имеющегося и популярного" и тут уже "при всём богатстве выбора" (tm) оказывается, что кроме Java и смотреть не на что. (С миром решений на основе MS я почти не контачу.) В случае повышенной "наукоёмкости" задачи Java преобразуется в Scala или Clojure:) Разумеется, если уговорить людей и начальство на бутерброд, становится в чём-то легче. То, что должно быстро бегать, делается на C/C++, иногда даже на ассемблере, а верхняя логика делается на Python, Erlang, Haskell, и ещё куче страшных слов, кому что ближе в конкретный исторический момент (но ширнармассы тянутся, по понятной причине, к Python). Вот только потом отлаживать такие бутерброды иногда более чем сложно. Ошибка в сишном коде, исключение из C++, показанное в верхнем питоновом слое, может выглядеть так, что не имеет ничего общего с тем, что её вызвало. И я понимаю тех, кто хочет пусть в 3 раза медленнее идеала, но единообразно. (Мы ещё не пробовали Cython - под него надо ещё продумать заточку инфраструктуры...) > А спада > популярности python не особо заметно, несмотря на засаду py2/py3, появление новых > интересных языков и проч. Она и не должна была пока активно спадать, скорее наоборот. Но это из-за общего тренда "все на веб!", который ещё активен. > Плюс, не все реализации python имеют GIL.  Как-то не заметно, чтобы > jython/ironpython стали сильно популярными. IronPython мы для себя оценивали и отвергли нафиг, потому что оно несовместимо с Unix, как только начинается какая-то системозависимая возня (начиная с открытия пайпов и порождения процессов). А жаль - могло бы получиться хорошим средством для ускорения реализации ещё во времена 2.5. Jython тогда был живой только для 2.2, а мы уже твёрдо сидели на 2.4/2.5... да и сейчас живой только для 2.5, и альфа для 2.7 - это несерьёзно. Не знаю, что первично - их непопулярность или их отставание - но таким образом они не смогут завоевать успех. >> А так - да, никто ничего не должен. Они могли вообще забросить >> это и заняться подлёдной рыбалкой. Но зачем-то они стараются тянуть проект? > Делают то, что им нужно. Это сомнительно. Авторам собственно языка от него обычно ничего не нужно, кроме чисто академической репутации. Реально происходит какое-то обобщение запросов пользователей. Да, сейчас они таковы, что ~90% это веб уровня среднего сайта (от нас тут на днях ушёл человек в сторону Django с компанией). Соответственно скорость - не основной признак, а вот предельно прозрачная юникодность - практически основной. >>> Чиво?  Там дофига работы со строками.  ipython - так просто >>> интерактивная оболочка для Python. >> От неё требуется скорость именно работы с текстами? > Скорость там в этом месте вряд-ли требуется, не для типичных случаев, как > минимум.  Так и в ваших сетевых приложениях, я чай - > латентность более существенна, чем ожидаемые вами проблемы от использования юникода. В случае SIP (сигнализации; я не говорю собственно про медиа, с ней другая история), как ни странно, таки не так. Латентность как таковая не существенна, если она, грубо говоря, не больше полсекунды. А вот перегруженность протокола именно текстовыми особенностями (сложная грамматика, всевозможные свободы в стиле IETF) - приводит к тому, что эта работа превращается в ~50% в работу над текстом. Остальное - внутренняя логика. (Вообще в VoIP нормально средства нет, каждое со своими извращёнными тараканами, но они принципиально несовместимы, потому что живут в разных средах:)) >>> Если эти изменения действительно масштабные - вам надо хорошо подумать головой над >>> реорганизацией кода. >> Ну да, только авторы питона в белом > Ну предложите как надо было сделать изменения работы со строками обратно совместимыми, > без превращения кода в несопровождаемую капусту.  Каждый мнит себя стратегом... Ну тот же six, но на уровне языка (чтобы не давал дополнительных тормозов), показывает вполне правильное направление движения. Можно было сделать мягкий переход по всем параметрам; я не нашёл, где реформы настолько серьёзные, что не могут быть решены в стиле "временно оставляем алиасы, которые будут снесены ровно через 2 версии".
	Ответить | Правка | Наверх | Cообщить модератору

	252. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 07-Янв-14, 23:46
	> Если с использованием numpy и тому подобных, то используют не Питон, а > его бутерброд с быстрым сишным кодом. cython - это тоже питон. >>> Проблема в том, что в итоге пользователи голосуют ногами, потому что альтернатива >>> есть и её (альтернативы) провайдеры активно тянут в свою сторону. А >>> авторы говорят на это "ну видите, никто же не сделал...", когда >>> те, кто могли сделать - просто убежали. >> Может оно и так, но "убежали" - требует доказательств. > Я просто видел живые примеры Живые примеры интересны тогда, когда становятся статистикой.  Наверное, вы сталкивались и с миграцией на питон, нет? > Она и не должна была пока активно спадать, скорее наоборот. Но это > из-за общего тренда "все на веб!", который ещё активен. Питон в этой области далеко не один. >>> А так - да, никто ничего не должен. Они могли вообще забросить >>> это и заняться подлёдной рыбалкой. Но зачем-то они стараются тянуть проект? >> Делают то, что им нужно. > Это сомнительно. Авторам собственно языка от него обычно ничего не нужно, кроме > чисто академической репутации. Да ну?  Гвидо в Google явно не академическими вещами занимался ;) > Да, сейчас они таковы, что ~90% это веб уровня среднего сайта > (от нас тут на днях ушёл человек в сторону Django с компанией). Не знаю откуда такие конкретные цифры.  Тот же scipy - огромная ниша: matlab/octave, fortran, всякие символьные и околосимвольные вычисления (напр. Theano).  Плюс, всякие системные утилиты, сервисы - все это традиционная область применения питона (в отличие от того же PHP).  То что разработчики языка пожертвовали в данном случае производительностью - мягко говоря, не обоснованно.
	Ответить | Правка | Наверх | Cообщить модератору

	244. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Филипп Филиппович (ok), 07-Янв-14, 22:31
	> Почему у JVM, .NET машины нет таких проблем и они не плачутся на то, что не могут держать один лок на всех? Вот именно. Это говорит о том, что сама архитектура виртуальной машины Python, мягко выражаясь, не очень актуальна. И как по мне, так я был бы рад, чтобы в прошедшие 5 лет менялось именно это. Понятно, что сломался бы весь API для C. Но за 5-6 лет это бы можно было починить.
	Ответить | Правка | К родителю #227 | Наверх | Cообщить модератору

	255. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–1 +/–
	Сообщение от myhand (ok), 07-Янв-14, 23:55
	> Понятно, что сломался бы весь API для C. Но за 5-6 > лет это бы можно было починить. А вот мы любим иметь этот API (в том же scipy).  Так что то, что его не ломают лишний раз на потеху веб-песателям - большой спасибо разработчикам питона.
	Ответить | Правка | Наверх | Cообщить модератору

	219. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от dwede (?), 04-Янв-14, 04:44
	> Что противоестественного в том, что 2/3 будет 0? Это в большинстве языков так А сколько вы их знаете?
	Ответить | Правка | К родителю #143 | Наверх | Cообщить модератору

	226. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от netch (ok), 07-Янв-14, 14:26
	>[оверквотинг удален] > предполагается многоязычность? И ведь всё равно будет полно ситуаций, когда о > понятии "кодировка" нужно помнить. Нет, поймите правильно, это всё очень красиво > и логично. Но стоило ли конкретно это изменение сопряжённых с ним > проблем? ИМХО, не стоило совершенно. В Python 2 кухню с кодировками > нужно было понять ровно один раз, и ни для кого, кроме > писателей хелловорлдов, это проблемы не составляло, а в итоге разруливанием именно > этой проблемы сломано, боюсь, не менее 70% того кода, который ломается > при переходе со второй ветки на третью. То есть отказавшись от > одного, экстремистского по сути своей, изменения, можно было этак втрое уменьшить > количество проблем портирования. Частично согласен, но в том смысле, что этот переход был неизбежен, только его надо было сделать мягче. Оставить префикс u (вернутый в 3.3), ввести префикс b, сделать раздельные типы bytes и unicode, и дать аккуратно портироваться на это. И затем делать второй этап, когда, например, list(b'abc') даёт числа, а не символы. Или вообще его не делать так, а ввести отдельные функции. > А прежняя семантика оператора деления кому мешала? Что противоестественного в том, что > 2/3 будет 0? Это в большинстве языков так, и ни один > язык пока именно от этого не умер. Вот это как раз я считаю правильным изменением, и жаль, что новый вариант не был изначально. А смысл очень прост: когда суть операции принципиально меняется от того, что один из операндов вдруг сменил тип на схожий в пределах совместимого - это недопустимо. Аналогия для "большинства языков" вроде Си не подходит потому, что в них типы статические и там в разы легче проследить, какие типы в операции; хотя и там такое объединение двух разных операций некорректно. Если считать нормальным разницу в выполнении деления из-за типов операндов, то следующим придётся признать нормальными, например, шуточки Javascript, где 5-"3"==2, но 5+"3"=="53", и аналогичные автоконверсии Perl/PHP/etc. Питон никогда не позволял такие автоконверсии и игнорирования подачи неправильных данных на вход (как в том же Javascript, где parseInt("08")==0), и это правильно - создаётся значительно меньше скрытых багов в коде. > Наверное, массовый переход на Python 3 состоится всё равно. Но он > мог бы быть гораздо легче, если бы в чисто внешнем причёсывании > языка было допущено чуть меньше радикализма. Вот вполне можно было поломать > не 70% кода, а 5%, и тогда портирование было бы куда > как проще. Тут меня больше всего удивляет, например, игра между range и xrange, items и iteritems... Зачем было убивать старое понимание? Кому оно реально мешало? Зачем эти итераторы во всём? > И меня удивляет, когда великодушный диктатор говорит, что GIL -- это нормально. > В итоге вместо многопоточного сервера приходится писать какой-то ужас то на > greenlets, то на Twisted с обязательной расшивкой обработчиков на куски сопрограмм > и обёртыванием каждой длительной операции неизвестно во что, и заниматься кучей > подобных, пусть иногда красивых по идеям и реализации, но лишних в > контексте прикладной задачи вещей. А если бы там была полноценная многопоточность, > было бы гораздо проще. Там, где нужна действительно параллельная обработка, предлагается > ограничиваться техникой fork. Но это же безумие, поскольку безо всякой нужды > усложняет отладку и архитектуру приложения. Иногда fork -- отличное решение, но > почему это должно быть единственной возможностью? Тут хорошо было бы сделать в пределах одного процесса несколько "доменов", каждый со своим GIL и пулом тредов, и выделенными точками обмена. Не между отдельными процессами, как сейчас в multiprocessing. Я согласен, что устранять GIL очень дорого. Но можно и без его устранения достаточно просто решить эти же задачи. > Словом, при принятии некоторых решений разработчиками языка и CPython был сделан очень > странный выбор. И этот выбор уже породил проблемы. Надеюсь, всё разрешится > в ближайшие несколько лет. Но большинства проблем могло бы и не > быть... И опять-таки - 5 лет это минимальный срок, чтобы пощупать со всех сторон и принять следующее принципиальное решение. Посмотрим, куда оно пойдёт.
	Ответить | Правка | К родителю #143 | Наверх | Cообщить модератору

	232. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 07-Янв-14, 16:17
	> Частично согласен, но в том смысле, что этот переход был неизбежен, только > его надо было сделать мягче. Оставить префикс u (вернутый в 3.3), > ввести префикс b Для обеспечения подобной совместимости - люди написали сторонние модули, напр. six.  Нет никакой нужды было тащить это в потроха CPython. >> А прежняя семантика оператора деления кому мешала? Что противоестественного в том, что >> 2/3 будет 0? Это в большинстве языков так, и ни один >> язык пока именно от этого не умер. > Вот это как раз я считаю правильным изменением, и жаль, что новый > вариант не был изначально. А смысл очень прост: когда суть операции > принципиально меняется от того, что один из операндов вдруг сменил тип > на схожий в пределах совместимого - это недопустимо. Плевать на математику - еще менее допустимо. На какой еще "схожий" да еще "совместимый" тип вы собираетесь сменять?  На float что-ли?  Так float и bigint - две огромные разницы, только школота мешает в одную кучу точную арифметику и операции с числами в формате с плавающей точкой.  То, что тут пошли на встречу школоте, да еще ввели лишний оператор - грустный факт. > Тут меня больше всего удивляет, например, игра между range и xrange, items > и iteritems... Зачем было убивать старое понимание? А зачем его сохранять, если py2 и py3 все-равно несовместимы?  Или вы против самого изменения?
	Ответить | Правка | Наверх | Cообщить модератору

	236. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от netch (ok), 07-Янв-14, 19:32
	> Плевать на математику - еще менее допустимо. > На какой еще "схожий" да еще "совместимый" тип вы собираетесь сменять?   > На float что-ли?  Так float и bigint - две огромные > разницы, только школота мешает в одную кучу точную арифметику и операции > с числами в формате с плавающей точкой. Раз школота их мешает в одну кучу, значит, это школота написала Питон. Потому что она в принципе позволила при проектировании языка делать неявные конверсии из (big)int во float. И во главе этой школоты - князь Гвидон. Вы, как говорится, или трусы наденьте, или крестик снимите. Или мы в принципе не допускаем произвольного смешения этих типов, всё только через явную конверсию. Тогда проблемы с определением смысла операции, действительно, нет, но действие типа 5.0/2 должно вызывать исключение, потому что типы несовместимы. Это подход, например, Go (причём там даже нет неявной конверсии между 32-битным uint32 и таким же 32-битным unsigned int). Хочешь конверсии - задай явно и уточни, как именно (может, тебя не устраивает режим округления по умолчанию). Или же мы допускаем смешение, но в таком случае эти две операции *надо* разделять. Питон выбрал более традиционный путь, и я не считаю, что это так уж плохо. >> Частично согласен, но в том смысле, что этот переход был неизбежен, только >> его надо было сделать мягче. Оставить префикс u (вернутый в 3.3), >> ввести префикс b > Для обеспечения подобной совместимости - люди написали сторонние модули, напр. six.   > Нет никакой нужды было тащить это в потроха CPython. Посмотрел, ужаснулся, спасибо. Если мы ещё и это будем дёргать на каждый чих... тут и так каждая лишняя функция проверяется на то, нельзя ли обойтись без неё, потому что вызов функции - страшно дорогое действие. А ещё и, например, six.b() на каждый такой литерал? Извините, это несерьёзно. >> Тут меня больше всего удивляет, например, игра между range и xrange, items >> и iteritems... Зачем было убивать старое понимание? > А зачем его сохранять, если py2 и py3 все-равно несовместимы?  Или > вы против самого изменения? Да, я считаю, что оно не нужно. Ничего вредного в xrange, dict.items() который выдаёт список и т.п. - не было.
	Ответить | Правка | Наверх | Cообщить модератору

	239. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 07-Янв-14, 21:33
	> Раз школота их мешает в одну кучу, значит, это школота написала Питон. Нет, только то, что его разработчики пошли на поводу у школоты :) > Потому что она в принципе позволила при проектировании языка делать неявные > конверсии из (big)int во float. Да, отмена таких смешений типов - и есть более корректный (с точки зрения математики) путь.  Но выбрали, увы, нечто более "по заявкам трудящихся". >> Для обеспечения подобной совместимости - люди написали сторонние модули, напр. six. >> Нет никакой нужды было тащить это в потроха CPython. > Посмотрел, ужаснулся, спасибо. Если мы ещё и это будем дёргать на каждый > чих... тут и так каждая лишняя функция проверяется на то, нельзя > ли обойтись без неё, потому что вызов функции - страшно дорогое > действие. А ещё и, например, six.b() на каждый такой литерал? Сколько-ж именно их у вас?  "Чую бесовщину" (ц) >>> Тут меня больше всего удивляет, например, игра между range и xrange, items >>> и iteritems... Зачем было убивать старое понимание? >> А зачем его сохранять, если py2 и py3 все-равно несовместимы?  Или >> вы против самого изменения? > Да, я считаю, что оно не нужно. Ничего вредного в xrange, dict.items() > который выдаёт список и т.п. - не было. Лишние интерфейсы.  Сейчас range возвращает итератор, а последовательности (list, tuple, etc) - можете получить, натравив на это соответствующий конструктор.  И не нужно никаких дополнительных iteritems. Другое дело, что обеспечить совместимость здесь было гораздо проще чем со строками (там вообще - непонятно как это сделать).  Видимо, просто решили не заморачиваться, раз интерпретаторы несовместимы все равно...
	Ответить | Правка | Наверх | Cообщить модератору

	246. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от netch (ok), 07-Янв-14, 22:50
	>> Раз школота их мешает в одну кучу, значит, это школота написала Питон. > Нет, только то, что его разработчики пошли на поводу у школоты :) В данном случае они пошли на поводу у традиции, потому что она банально освящена временем. И только набрав опыта и набив шишки - начали осознавать, чем плохи такие решения. Или же не имели возможности провести нужные решения раньше, пока вся масса не сдвинется. Вон с тем же делением Вирт возмутился раньше. Но где теперь та Модула? И где Си, в котором на проблему успешно плюнули? >> Потому что она в принципе позволила при проектировании языка делать неявные >> конверсии из (big)int во float. > Да, отмена таких смешений типов - и есть более корректный (с точки > зрения > математики) путь.  Но выбрали, увы, нечто более "по заявкам трудящихся". Опять-таки вопрос в грандиозности реформы после того, как язык был реализован по принципу "возьмём то, что делают большинство на момент этого проектирования, а потом будем разбираться, что было неправильно". На сейчас отменять автоконверсию int->float значит, мне кажется, делать ещё более суровый перелом, чем при создании 3.0. >>> Для обеспечения подобной совместимости - люди написали сторонние модули, напр. six. >>> Нет никакой нужды было тащить это в потроха CPython. >> Посмотрел, ужаснулся, спасибо. Если мы ещё и это будем дёргать на каждый >> чих... тут и так каждая лишняя функция проверяется на то, нельзя >> ли обойтись без неё, потому что вызов функции - страшно дорогое >> действие. А ещё и, например, six.b() на каждый такой литерал? > Сколько-ж именно их у вас?  "Чую бесовщину" (ц) Ой много. Все основные ключевые слова и распространённые значения параметров из SIP'овских RFC, из стандартных словарей RADIUS, словаря Cisco, собственного словаря... Но six.b() на константы ещё полбеды, это можно организовать при загрузке модуля (думаю, сильно скорость не пострадает). А вот то, что в ряде случаев (этак несколько сотен) нужен именно dict.items() как список, а рисовать всегда list() это означает вызов ещё одной функции и потерю на этом... даже код на 2.* при подготовке этого перехода уже потеряет в скорости. А что будет, когда переход закончится - ХЗ. Я уже подумываю взять какой-то стандартный препроцессор типа m4 и прогонять код через него. В рантайме это будет явно дешевле six'овских вызовов. Кстати, именно тему получения списка ключей/атрибутов/пар six не закрыл. Я понимаю, что для него list() вокруг уже готового списка ерунда, но я тут за каждый call per second бьюсь. >>>> Тут меня больше всего удивляет, например, игра между range и xrange, items >>>> и iteritems... Зачем было убивать старое понимание? >>> А зачем его сохранять, если py2 и py3 все-равно несовместимы?  Или >>> вы против самого изменения? >> Да, я считаю, что оно не нужно. Ничего вредного в xrange, dict.items() >> который выдаёт список и т.п. - не было. > Лишние интерфейсы.  Сейчас range возвращает итератор, а последовательности (list, tuple, > etc) - можете получить, натравив на это соответствующий конструктор.  И > не нужно никаких дополнительных iteritems. Только вот измерения показывают, что на 2.7 на большом словаре (я брал в качестве характерного размера 10000) list(d.iteritems()) дороже d.items() на четверть. Это уже даёт проблему на самом переходе: я для него должен, получается, заведомо замедлить программу. После этого, да, переход на тройку уже ускоряет. (Полный цикл - 4.0 на 2.7/items, 4.5 на 2.7/list(iteritems) и затем 3.3 на 3.3/list(items).) В общем, переход не гладкий. > Другое дело, что обеспечить совместимость здесь было гораздо проще чем со строками > (там вообще - непонятно как это сделать).  Видимо, просто решили > не заморачиваться, раз интерпретаторы несовместимы все равно... Похоже на то. Но про строки я не согласен - там плавный переход тоже делается без особого напряга.
	Ответить | Правка | Наверх | Cообщить модератору

	245. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Филипп Филиппович (ok), 07-Янв-14, 22:35
	Кстати, верно, range/xrange -- ещё одна странность. > Я согласен, что устранять GIL очень дорого. Но можно и без его устранения достаточно просто решить эти же задачи. Это дорого при сохранении существующей архитектуры VM. При сохранении C API. Но за пять-шесть лет можно было бы восстановиться и после их слома. А так -- до сих пор не восстановились (далеко не всё портировано), а плюсов от Py 3 не так и много.
	Ответить | Правка | К родителю #226 | Наверх | Cообщить модератору

	256. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–1 +/–
	Сообщение от myhand (ok), 07-Янв-14, 23:58
	> Кстати, верно, range/xrange -- ещё одна странность (). Зачем две разных интерфейса для пользователя? >> Я согласен, что устранять GIL очень дорого. Но можно и без его устранения достаточно просто решить эти же задачи. > Это дорого при сохранении существующей архитектуры VM. При сохранении C API. Но > за пять-шесть лет можно было бы восстановиться и после их слома. Про "можно было" вполне годится аргумент - "сперва добейся".   Учитывая еще и то, что *существующие* реализации питона без GIL так и не привлекли к себе достаточной аудитории... Вобщем, давайте завязывать с полетами фантазий про "можно было бы" ;)
	Ответить | Правка | Наверх | Cообщить модератору

	251. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от Филипп Филиппович (ok), 07-Янв-14, 23:25
	Впрочем, надо признать, что вряд ли кто-то предполагал настолько длительный процесс перехода. Если бы предполагал, возможно, и решения были бы иными. В чём-то -- более умеренными, а в чём-то -- более радикальными.
	Ответить | Правка | К родителю #226 | Наверх | Cообщить модератору

152. "Стратегия параллельного поддержания веток Python 2 и Python ..."	–2 +/–
Сообщение от Главные Редакторы (ok), 01-Янв-14, 22:43
Поздравляю, товарищи! Мы с вами имеем честь видеть как был выпилен (в хорошем смысле, доделан, доведён до совершенства) ещё один очень хороший язык программирования. Ибо любые изменения которые пытаются в него внести, приносят только вред. Но Алекс Гейнор (Alex Gaynor) этого не понимает, и поэтому делает ошибочный вывод что виноват "питон-2", только тем, что он ("питон-2") существует. Смешно слушать угрозы разработчиков "питона" о прекращении поддержки "питона-2". У нас в конторе сидят на 2.7 и в ус не дуют, а работа кипит и заказчики довольны как слоны, какое им (заказчикам) и нам дело до "прекращения поддержки"? И вообще - зачем нужно менять что то в языке, если эти изменения можно сделать при помощи утилиты 2to3? Может легче в третий питон встроить эту утилиту, и пусть она делает чёрную и никому не нужную (кроме разработчиков третьего питона) работу? Тогда смысл нововведений 3его питона теряется, а значит "питон-3" - не нужен!
Ответить | Правка | Наверх | Cообщить модератору

	155. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 02-Янв-14, 01:58
	> У нас в конторе сидят на 2.7 и в ус не > дуют, а работа кипит и заказчики довольны как слоны, какое им > (заказчикам) и нам дело до "прекращения поддержки"? Заказчикам-то, понятное дело - никакое.  Они может про питон и слышать-то не слышали.  Вообще, им должно быть пофиг на чем вы там работу кипятите - хоч на ассемблере. Дело должно быть вам.  Если вы впариваете кому-то код для старой версии питона, которая не поддерживается - вам либо придется брать его поддержку на себя (устраняя баги, особенно являющиеся потенциальной проблемой для безопасности), либо - расписаться в том, что вы продаете заказчику некачественный продукт, пользуясь его наивностью.  Сомневаюсь, что вы потянете на первый вариант... > И вообще - зачем нужно менять что то в языке, если эти > изменения можно сделать при помощи утилиты 2to3? Ох, наивный вьюнош :)  Задумайтесь хоть над тем, что lib2to3 - это регэксповый хоррор.  Т.е. сплошные эвристики.  Уже только поэтому - все изменения ну никак сделать не выйдет. > Может легче в третий питон встроить эту утилиту Чтобы перед генерацией байткода по исходнику проходился энтот фиксер?  Синтаксис ведь - *разный*! 2to3 генерит, вообще говоря, с py2 - *несовместимый* код. Т.е. задача стоит следующим образом: 1) понять что дорогой исходник написан в расчете на старый синтаксис (else 3) 2) тогда прогнать 2to3 3) счастливо работать дальше. Такая вот парашютно-тормозная установка, чисто по-приколу - абы ентырпрайз был счастлив.  А не дофига-ли будет, только ради того что вы не хотите потратить время на портирование кода?  Ведь если продолжить эту "логику" - из языка ничего вообще нельзя будет удалить!  Ибо что-то - да придется переписывать.
	Ответить | Правка | Наверх | Cообщить модератору

	220. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+3 +/–
	Сообщение от web (?), 05-Янв-14, 04:02
	Так на заметку, представляю крупного заказчика. При принятии реализации проекта, будут вопросы/проверка совместимости кода с python3. Почему: Проект "долгоиграющий", он должен будет иметь поддерживаемый интерпретатор, как в плане баг-фиксов, так и в плане возможностей новых библиотек(python3) Из моего опыта, поддержка единой кодовой базы pure Python кода, совместимого с версиями 2.7 и 3.3 не должна быть сколько-нибудь сложной.
	Ответить | Правка | К родителю #152 | Наверх | Cообщить модератору

	221. "Стратегия параллельного поддержания веток Python 2 и Python ..."	+/–
	Сообщение от myhand (ok), 05-Янв-14, 13:01
	> Из моего опыта, поддержка единой кодовой базы pure Python кода, совместимого с > версиями 2.7 и 3.3 не должна быть сколько-нибудь сложной. Даже начиная с 2.6.
	Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема