tag:blogger.com,1999:blog-4428473564097379725.post6029350162397192444..comments2024-03-14T06:42:34.180+05:00Comments on Ещё один блог сисадмина: Генераторы и сопрограммы Python. Часть 2morbohttp://www.blogger.com/profile/16650057587203469226noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-4428473564097379725.post-40718384769719718332013-01-28T11:39:37.118+06:002013-01-28T11:39:37.118+06:00>Это плохая затея, особенно если планируется ис...>Это плохая затея, особенно если планируется использовать подпрограмму в других программах: что-то мне подсказывает, что кто-то на этом огребёт трудновылавливаемых проблем. Причём там, где их меньше всего ждёшь.<br /><br />Этот объект является представлением сопрограммы. Согласитесь, несколько странно, если мы описываем сопрограмму, а потом пользуемся ей, как объектом. Поэтому именно в этом случае маскировка оправдана.<br /><br />>Последняя фраза выдаёт ковбоя с головой :-) Кстати, в тексте wrapper не документирован ни разу.<br /><br />Это учебный пример, поэтому wrapper так незатейливо назван и описан только в самом тексте статьи. Wrapper - это обёртка, которая позволяет использовать сопрограмму как менеджер контекста в операторе with. Код его быстрее прочитать, чем описывать.<br /><br />Лучше быть ковбоем, чем стадом мычащих коров :)<br /><br />>Это я к чему: компилятор с кодом разберётся, конечно, но не факт, что он его интерпретирует так, как задумывалось автором.<br /><br />Нужно привыкнуть к этому, как к данности. Если хотите, чтобы программа не разваливалась при каждом изменении - покройте её тестами, а каждый тест продокументируйте. Без тестов вообще нет никаких гарантий того, что написанное делает то, что ожидается. Без них вообще зачастую проще будет переписать программу заново, чем что-то пытаться в ней изменять.<br /><br />Все языки программирования разные, имеют множество не очевидных нюансов, которые ещё и меняются со временем. Программисты тоже мыслят по-разному и пользуются разными приёмами. Тут вообще сложно что-то гарантировать. Есть громкие примеры, как с <a href="http://avva.livejournal.com/2323823.html" rel="nofollow">оптимизированной версией memmove в glibc</a> или <a href="http://www.opennet.ru/opennews/art.shtml?num=20944" rel="nofollow">системным вызовом close, возвращающим ошибку</a>. Python, с его периодическими изменениями и с разным поведением в разных версиях, вообще - не самый лучший язык для написания надёжных программ с долгим сроком поддержки.morbohttps://www.blogger.com/profile/16650057587203469226noreply@blogger.comtag:blogger.com,1999:blog-4428473564097379725.post-91171123158341558752013-01-28T07:06:47.166+06:002013-01-28T07:06:47.166+06:00>> Во-первых, хочется замаскировать отправку...>> Во-первых, хочется замаскировать отправку значений в подпрограмму так, <br />>> чтобы это выглядело как простой вызов функции, а не вызов метода объекта.<br /><br />Это плохая затея, особенно если планируется использовать подпрограмму в других программах: что-то мне подсказывает, что кто-то на этом огребёт трудновылавливаемых проблем. Причём там, где их меньше всего ждёшь.<br /><br />>> Читается, на мой взгляд, хорошо - код компактен и его логика легко просматривается, <br />>> ___если понимать, для чего нужен wrapper___. <br /><br />Последняя фраза выдаёт ковбоя с головой :-) Кстати, в тексте wrapper не документирован ни разу. <br /><br />Пример: не далее как нынче утром автор этих строк правил один алгоритм и портировал его на С. Всё ОК, но пару дней назад автор этих строк поправил некий параметр nmax и сделал его nmax=1 (это число итераций). И забыл, естественно, после бурных выходных. А теперь алгоритм расходится с эталонным алгоритмом, причём капитально так расходится. Автору потребовалось добрых полчаса на выяснение этого факапа, а ведь алгоритм состоит из 300 строк кода, и "поправлен" неделю назад.<br /><br />Это я к чему: компилятор с кодом разберётся, конечно, но не факт, что он его интерпретирует так, как задумывалось автором.virenshttps://www.blogger.com/profile/12420257446841864325noreply@blogger.com