Сдвоенный выпуск PyPy2.7 и PyPy3.5 v6.0

И самое главное: в силу п.2, на динамике дьявольски трудно рефакторить. Никакой помощи от компилятора.

Нормально написанный проект вполне себе хорошо рефакторится. Говнокод - да, рефаторить сложно. Но откровенный говнокод на питоне проще просмотреть и переимплементить, чем рефакторить «по-джавовски».

А для больших долгоиграющих проектов скорость и надёжность рефакторингов - критична.

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

Можно ссылку на статистику?.

Готовой ссылки под рукой нет. Фраза «до 5 раз» фигурирует во многих руководствах по питону. Личный опыт крупных проектов подтверждает ее корректность (более того, возможно цыфирь и занижена или варьируется в зависимости от предметной области).

по статистике ЯП с динамикой сокращает объем кода до 5 раз

Можно ссылку на статистику?

Готовой ссылки под рукой нет.

Я думаю, что если эта фантастическая ссылка и существует, то она сравнивает Python с чем-то вроде Си, в крайнем случае - Си++. Там текст может быть и в самом деле в разы меньше (хотя я очень сильно сомневаюсь в 5 разах).

Нормально написанный проект вполне себе хорошо рефакторится. Говнокод - да, рефаторить сложно.

Код одинакового качества рефакторится в статически типизированном языке (Си++, даже Си) в разы проще, чем в динамически типизированном (Python).

Динамически типизированные языки называют «языками прототипирования» потому, что код на них практически невозможно переписывать - только писать заново (на другом языке).

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

Далеко не только в энтерпрайз, и далеко не только в жава. Например, он критичен при эволюционировании архитектуры (в т.ч. какой-либо подсистемы), что случается весьма часто (в т.ч. в связи с изменяющимися требованиями, в т.ч. в процессе разработки новых фичей). Мне казалось общеизвестным и очевидным утверждение, что хорошая архитектура - всегда результат рефакторингов. Просто потому что «большой работающий проект всегда вырастает из маленького работающего проекта; большой проект, полностью спроектированный на бумаге, никогда не заработает» (с) не помню чьё.

Динамически типизированные языки называют «языками прототипирования» потому, что код на них практически невозможно переписывать - только писать заново (на другом языке).

Крайне спорное утверждение, поскольку и рефакторингом и переимплементацией на питоне приходится заниматься регулярно в крупных проектах.

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

Весьма странно верить «написанному на заборе», когда на практике приходится делать ровно наоборот - проектировать сначала на бумаге, а потом уже воплощать в коде.

Да что тут спорного. В Python, как уже было сказано выше, транслятор в рефакторинге не помогает вообще никак, а в Си++, например, помогает и даже очень. Это просто факты.

хорошая архитектура - всегда результат рефакторингов

))) Хорошая архитектура - это результат продуманной работы архитектора. Рефакторинг дает хорошую имплементацию, а не архитектуру. Если начинать с паттерна «из говна и палок», то эпическая битва с рефакторингом даст просто посредственный результат. Единственный плюс такого подхода - с самого начала код будет что-то делать.

Хорошая архитектура - это результат продуманной работы архитектора

Его работа так же итеративна, как и работа кодера. Можешь назвать это «рефакторингом архитектуры».

транслятор в рефакторинге не помогает вообще никак

Если использовать неуникальные имена, то да, в динамике сложно рефакторить. Если именования уникальны - транслятор не нужен. Достаточно хорошоего IDE.

Его работа так же итеративна, как и работа кодера. Можешь назвать это «рефакторингом архитектуры».

Само собой, но к статике/динамике это мало привязано.

Можно сказать и так, но рефакторинг архитектуры влечет за собой переделку кода.

Хорошая архитектура - это результат продуманной работы архитектора.

Ещё раз: архитектура может эволюционировать со временем. И на долгоиграющих проектах почти всегда так и делает.

рефакторинг архитектуры влечет за собой переделку кода

архитектура может эволюционировать со временем

Несомненно. И если изначальная архитектура говенная, или в процессе на нее забили - да, рефакторить крайне сложно. Пример: в проекте был задекларирован MVC. Но в процессе «костылирования», код проекта превратился в монолитный блоб - в модели документа куски контроллеров и даже фрагменты UI, в UI код контроллеров и работа с моделью и т.п. (ясное дело - токмо ради удобства). И все это от души присыпано «магией» аля создания пакетов в рантайме, модификацией объектов в рантайме и пр. Пока костылируется проект - все идет весело и легко. Как встал вопрос про портирование на другую ОС и смену контроллов - тут же ппц и приехал. Да, на джаве подобную фигню можно отрефакторить, затратив хз сколько времени, переписав 2-3 раза весь код по ходу. На питоне дешевле написать заново. Но в целом, проблема завязана не на ЯП, а на то, что пейсателям вовремя клизьму не прописали :) Если бы сохранялась модульность и соответствие MVC - код бы жил и работал дальше, а менялись бы только те части, которые подлежат изменениям.

Что-то у вас мысли крутятся лишь вокруг говно-архитектуры и костылей. Реальное говно и на жаве проще переписать с нуля, чем рефакторить - подтверждаю. Но я говорил вообще не про такие сценарии. К примеру: есть HTTP/1.1-сервер, вышел стандарт HTTP/2. Внутренние структуры и алгоритмы сервера на такую подставу вообще не расчитаны. С нуля переписывать? Охренеешь, плюс там такое количество ньюансов, что не вспомнишь и не охватишь. Рефакторинги, только рефакторинги. Постепенно приближающие потроха сервера к требуемым для поддержки HTTP/2.

А ещё вспомнился чисто организационный вариант: «дешевле переписать заново» для начальства может оказаться недёшево. А время на рефакторинги я могу размазывать между другими тикетами.

А ещё вспомнился чисто организационный вариант: «дешевле переписать заново» для начальства может оказаться недёшево. А время на рефакторинги я могу размазывать между другими тикетами.

При этом если вместе с переписывальщиком над проектом одновременно работают другие люди, потом хрен смержишься. А рефакторинги можно делать и мержить поэтапно.

К примеру: есть HTTP/1.1-сервер, вышел стандарт HTTP/2. Внутренние структуры и алгоритмы сервера на такую подставу вообще не расчитаны. С нуля переписывать?

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

время на рефакторинги я могу размазывать между другими тикетами

Как показывает практика, это неэффективно. Нет полного погружения в задачу. Гораздо дешевле выделить время на решение проблемы, чем делать урывками. Выполнение таска состоит из трех этапов:

1.Въехать в сабж 2.Сделать решение 3.Техническое завершение задачи.

Если задача делается урывками, этапы 1 и 3 постоянно повторяются, а это бесполезная трата времени. Если нашинковывать ну очень уж мелко, бОльшая часть времени по итогу уйдет на этапы 1 и 3, нещадно дублируясь.

При этом если вместе с переписывальщиком над проектом одновременно работают другие люди, потом хрен смержишься. А рефакторинги можно делать и мержить поэтапно.

Вести отдельную бренчу и время от времени подмердживать мастер религия запрещает? ))) Тем паче, что переписывается обычно отдельный фрагмент, в котором другие не делают на данный момент изменений.

Наворачивать в одни и те же потроха и один и другой стандарты - неразумно.

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

Как показывает практика, это неэффективно.

Полностью согласен, но вариантов к сожалению нет, т.к. время на рефакторинги начальство как правило не выделяет. Знавал я одного типа, который говорил: «не выделяет, значит и пофиг, не будем рефакторить»; но это прямой путь к жопе.

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

Значит у вас косяк в архитектуре, раз протоколы прибиты в коде ржавыми шурупами. Они должны быть независимыми друг от друга сущностями, иначе это «спагетти стайл».

Вести отдельную бренчу и время от времени подмердживать мастер религия запрещает? )))

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

А при переписывании - с хорошей вероятностью идёт к чёрту и старая структура кода, и старые имена - всё. Тут уже что «время от времени» подмерживать, что в конце: геморрой в обоих случаях. Механически не получится.

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

Только тем и живём.

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

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

Значит у вас косяк в архитектуре, раз протоколы прибиты в коде ржавыми шурупами. Они должны быть независимыми друг от друга сущностями, иначе это «спагетти стайл».

Во-первых, в эффективной, тщательно оптимизированной реализации чего бы то ни было не может быть иначе. Любое абстрагирование, нагромождение слоёв - берёт плату эффективностью. Так что это не «косяк в архитектуре», а вопрос выбора целевой функции: скорость vs расширяемость.

Во-вторых, если вы в курсе, что такое HTTP/2 streams (по сути это слой легковесных connections между TCP и HTTP) и как пишется socket server на сях, то должны понимать, что для HTTP/1.1-сервера достаточно классической реализации сокет-сервера (ну, с поправкой на новомодный epoll), а дополнительный слой HTTP/2 streams требует соответствующего обслуживания во внутренних структурах сервера. Это самое что ни на есть ядро сервака - цикл обработки событий на коннектах; и не зная заранее про будущую необходимость дополнительного слоя между TCP и HTTP - ни в жисть не догадаешься на него заложиться, потому что ну это ж бред: давайте ещё на доп. слой между TCP и IP заложимся.

Так что ситуации очень разные бывают.

Хотя соглашусь, что большая часть рефакторингов - выпрямление отдельных кривых подсистем. Но тут тоже удобнее рефакторить, чем переписывать, если подсистема запутанная: при рефакторинге гарантированно ничего не упустишь и не поломаешь, потому что это чисто механическая процедура, её вообще на автопилоте можно делать (за что я её и люблю: мозги отдыхают). А поэтапность её выполнения можно синхронизировать с квантованием свободного времени: увидел, куда можно дальше копнуть - копнул, дальше тикеты делаешь. Следующий раз входишь в тему уже чуть в другом месте.

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

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

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

и не зная заранее про будущую необходимость дополнительного слоя между TCP и HTTP - ни в жисть не догадаешься на него заложиться, потому что ну это ж бред: давайте ещё на доп. слой между TCP и IP заложимся.

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

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

Можно подумать, что питон прям какая-то адская машина, ни разу не помогающая в работе ))) Тоже самое - и прогнать синтаксис и помодульно протестить в интерактивном режиме и продебажить с брейкпоинтами - все это в наличии.

Потому что метод - это функция, и явное лучше неявного.

Как по мне, это чистое теоретизирование. С практической точки зрения, разница синтаксисов o.f() и f(o) даёт полезную информацию об инкапсуляции при чтении кода: метод - значит объявлен в теле класса

>>> class foo: pass
... 
>>> def bar(self): print self
... 
>>> bar(foo())
<__main__.foo instance at 0x7fe47fb1ccb0>
>>> foo.bar = bar
>>> foo().bar()
<__main__.foo instance at 0x7fe47fb1ccb0>
>>> 

Это просто удобно.

Ах, да, это ж питон: ни инкапсуляции, ни приватных членов, ни final keyword. :)

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

что мы все наконец-то согласны, что питон 3 не тьюринг-полный.

вопрос скорее в том, насколько наполнен тьюрингом питон 2

Троллинг про Тьюринг полноту питона 3 это известная тема в англоязычном интернете. Странно, что местные про неё не слышали.

У нас тут импортозамещение.

Кто-нибудь может пояснить, зачем нужна эта свистопляска с разными интерпретаторами разных версий. Что именно в несовместимости версий мешало бы обойтись какой-нибудь дерективой в начале скрипта\модуля, чтобы интерпетировать их по-разному?

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

Прежде всего поменялись строки. В Python 3 str — это то, что раньше было unicode. Юникод вместо байтовых строк никакими директивами не решишь, с новыми строками нужно по-другому работать.

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

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

Теперь понял, о чём речь. Скорее всего, ребята хотели закопать Python 2 и побыстрее. Оставить юзерам возможность сидеть на привычной второй версии с такой точки зрения выглядит глупо.

Еще бы это сделало рантайм более жирным.

какой-нибудь дерективой в начале скрипта\модуля, чтобы интерпетировать их по-разному?

чтобы интерпетировать их по-разному, первой строчкой в начале скрипта пишешь #!/usr/bin/env python2, если это второй питон и #!/usr/bin/env python3, если третий. это и есть нужные тебе директивы.

А по-моему, он искренне тупой.

Совсем как ты.

А по статистике ЯП с динамикой сокращает объем кода до 5 раз.

И увеличивает объем тестов в 5 раз. Любишь писать тесты вместо кода? Ай, шалунишка.

Мсье, не порите чушь - ей больно :) Покрытие юнит-тестами в питоне ровно такое же, как в статических ЯП. Только и тесты в 5 раз меньше по объему.

А любой объект в питоне - это словарь!

Словарь - это тоже объект :)

Приведи пример, доказывающий неполноту Python по Тьюрингу.

не может интерпретировать код от питон 2.

Кресты тоже не могут, прикинь

А по статистике ЯП с динамикой сокращает объем кода до 5 раз

А отказ от велосипедостроения - раз в 30.

потому что он не тьюринг-полный. прув ми вронг.

доказательства - обязанность делающего утверждение. если таковых не имеется - утверждение ложно.

А отказ от велосипедостроения - раз в 30.

Знание stdlib и предметных библиотек еще ни в каком ЯП не отменили.

доказательства - обязанность делающего утверждение.

Это так.

если таковых не имеется - утверждение ложно.

А это чушь.

Если для некоего утверждения не имеется доказательств ни его истинности, ни его ложности, то утверждение не может считаться ни доказанным, ни опровергнутым.

Потому что, кроме вариантов «это так» и «это не так» существует ещё третий вариант: «мы не знаем, так это или не так».

А то так и до существования Б-га можно докатиться — никто же не доказал обратного.

По теме: пайтон, конечно же, тьюринг-полный, это вполне можно доказать. Но у того анона какое-то альтернативное мышление, так что доказывать это ему дело неблагодарное.

По теме: пайтон, конечно же, тьюринг-полный, это вполне можно доказать. Но у того анона какое-то альтернативное мышление, так что доказывать это ему дело неблагодарное.

Анонимус написал, что в заграничных интернетах это известная тема для троллинга: Сдвоенный выпуск PyPy2.7 и PyPy3.5 v6.0 (комментарий)

И действительно. А начал всё это старый тролль Zed Shaw в своей книге «learn python the hard way». Вот тут он пишет про «turing complete».

Покрытие юнит-тестами в питоне ровно такое же, как в статических ЯП. Только и тесты в 5 раз меньше по объему.

Это при условии отсутствия тестов обработки входных данных неправильных типов, что в статических ЯП отлавливается на этапе компиляции и потому в дополнительном тестировании не нуждается.

пайтон, конечно же, тьюринг-полный, это вполне можно доказать.

Приступай. Иначе балабол.

Приступай. Иначе балабол.

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

в статических ЯП отлавливается на этапе компиляции

Вполне достаточно типизации по соглашению. Не, ну если команда сплошняком из древесно-волокнистых даунов, которые пыжуют данные как бог на душу положит - то да, без строгой типизации не обойтись. Не случайно для индусов «джава нашефсио!» :)