LINUX.ORG.RU

Есть ли годные гайды по стилю для питона

 , ,


1

2

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

  • Не используй monkey patching (изменения классов и функций в процессе работы приложения) без крайней необходимости;
  • Не используй классы, если это не навязывает библиотека и тебе не нужно переопределить операторы, предпочитай duck typing. Следствие — статическая типизация в питоне не работает;
  • Лямбды — говно, и функциональная парадигма в питоне близка к неюзабельности из-за трудности передачи блока кода аргументом. Язык изначально ориентирован именно на импертивный код аля «башпортянка», потому предпочитай list comprehension/generator expression вместо filter-map;
  • Предпочитай пересоздавать простые значения с нужным типом, а не передавать их как есть или по ссылке. При изменении значения ячейки используй новые значения, а не изменяй старые обьекты. Под капотом CPython уже создает-высвобождает объекты на каждый чих. Создать строку из строки в питоне стоит примерно ничего, но если внезапно вместо строки подвернется непонятный тип или None, то код рискует свалиться со стэком в неожиданном месте.

PS: мои прошлые работы по теме, которые дают советы «как не делать», но не дают советов «что же делать»:

Объектная модель питона
https://habr.com/ru/post/481782/ - О проблемах транслятора Python и переосмысление языка

Перемещено leave из talks

★★★★

Последнее исправление: byko3y (всего исправлений: 1)
Ответ на: комментарий от anonymous

Если было тестовое задание, то тоже интересует его условие

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

? Что я должен был из этого понять?

В предыдущем посте ведь все сказано …

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

Уже определился.

И memory и базы на диске, которые друг с дружкой дружат ...

Что до реализации эффективного API для memory и баз, то они лишь похожи в своих целях …

anonymous
()
Ответ на: комментарий от byko3y

Спасибо за информацию. Пошел ты нахуй.

anonymous
()

Я внезапно осознал, что толком не могу сформулировать, какие фичи питона стоит использовать, а какие — нет (как в последнем треде по крестам).

Так какие в Си «три-пять лучших фич C++» нужны?
В треде какое-то общее мнение имеется? …

anonymous
()
Ответ на: комментарий от byko3y

Фу, ещё один ООпешнутый! Парни! Разбегаемся! Может покусать и заразить ООП!

Not_a_Troll
()
Ответ на: комментарий от anonymous

Так какие в Си «три-пять лучших фич C++» нужны?
В треде какое-то общее мнение имеется? …

В треде есть мое мнение, в треде есть статистика по всем голосовавшим, ближе к концу треда есть моя аналитика и объяснение, почему я так сгруппировал голоса.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Ну вот видишь, а пишешь «типы нужно знать до запуска».

Потому что если тебе ещё и типы надо дебажить, то кажется лучше сразу в простыню и на кладбище. Дебаггер нужен для бизнес-логики, чтоб понять почему один (новый, старые проверяются юнитами) из кейсов даёт результат отличный от ожидаемого

upcFrost ★★★★★
()
Ответ на: комментарий от upcFrost

Потому что если тебе ещё и типы надо дебажить, то кажется лучше сразу в простыню и на кладбище. Дебаггер нужен для бизнес-логики, чтоб понять почему один (новый, старые проверяются юнитами) из кейсов даёт результат отличный от ожидаемого

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

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Хочешь - С, хочешь - D, хочешь - С++!..

anonymous
()
Ответ на: комментарий от byko3y

Я не спорю, что типы должны быть определены и не плавать, но их лично мне не нужно «знать».

Их не нужно знать пока их не нужно приводить. Вот попробуй gql красиво в базу сложить - timestamp-число лучше в родной для базы вариант datetime перекинуть, id если не цифры то привести к uuid или objectid, enum тоже нужно транслировать.

Вроде операции ерундовые, но как ты сам сказал - ресурс внимания ограничен. Что-то забыл, типы расставлены - ide тебе подсветила что ты шланг. А то можно нечаянно захреначить в монгу строку вместо objectid и потом долго удивляться почему ничего найти не получается

upcFrost ★★★★★
()
Ответ на: комментарий от anonymous

Лучше гомосятина, пока другие меньшинства похлеще не подтянулись.

Virtuos86 ★★★★★
()
Ответ на: комментарий от byko3y

В питоне ты можешь объекту добавить любое свойство, не описанное в классе.

У NamedTuple нельзя. А у dataclass и вообще любого класса есть __slots__.

Хотя __slots__ мало кто пользуется в силу того, что никто умышленно «любое свойство» не присваивает. Опечатки отлавливаются в подавляющем большинстве случаев статическим анализатором pycharm. В случае когда используется сторонняя библиотека, где лютая динамика, и классы в runtime собираются - тут только тесты помогут.

qaqa ★★
()
Последнее исправление: qaqa (всего исправлений: 2)
Ответ на: комментарий от byko3y

Как C++ является пародией на ООП

Для своего развития. Можно пример языка без пародии на ООП, который получил широкое распространение?

anonymous
()
Ответ на: комментарий от anonymous

Смолток. Широкое распространение в узких, слегка волосатых кругах.

Virtuos86 ★★★★★
()
Ответ на: комментарий от qaqa

__slots__

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

Virtuos86 ★★★★★
()
Ответ на: комментарий от upcFrost

Вроде операции ерундовые, но как ты сам сказал - ресурс внимания ограничен. Что-то забыл, типы расставлены - ide тебе подсветила что ты шланг. А то можно нечаянно захреначить в монгу строку вместо objectid и потом долго удивляться почему ничего найти не получается

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от qaqa

А у dataclass и вообще любого класса есть __slots__

from dataclasses import dataclass

@dataclass
class C():
    __slots__ = "x"
    x: int = 1

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: 'x' in __slots__ conflicts with class variable

И такой весь питон. Нужно просто знать, по какому пути меньше всего граблей — для этого и нужны гайды.

Хотя __slots__ мало кто пользуется в силу того, что никто умышленно «любое свойство» не присваивает

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от anonymous

Можно пример языка без пародии на ООП, который получил широкое распространение?

Erlang же.

byko3y ★★★★
() автор топика
Ответ на: комментарий от Virtuos86

Я считаю, этот атрибут полезен, когда хочется сэкономить вычислительные ресурсы, чтобы в __dict__ не шариться, когда часто надо

По факту такая оптимизация превращается в трах, и нужна только потому, что для питона не существует универсальных и хорошо совместимых ускорялок выполнения. 20 лет прошло с первого проекта Unladen Swallow, и всё, что мы пока что имеем — это PyPy, на котором половина кода не работает.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

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

Virtuos86 ★★★★★
()

Есть ли годные гайды по стилю для питона

@byko3y, желаю вам в Новом Году выбирать инструменты АДЕКВАТНЫЕ для разработки и «борьба» с

Ветряными Мельницами ПРЕКРАТИТСЯ ...
anonymous
()
Ответ на: комментарий от anonymous

Еще одно пожелание ИГРОДЕЛАМ

Хватит вести разработку их с Драконами и всякой НЕЧИСТЬЮ.    
В этом мире и так не все позитивно, а вы всякую НЕЧИСТЬ ПЛОДИТЕ
anonymous
()
Ответ на: комментарий от Virtuos86

да забей ты на питон. это тебе пишет тот, кто считал когда-то питон эталоном практичного ЯП

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

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

Тьфу-тьфу, боже упаси. Хаскель — это программирование ради программирования, это даже не перфекционизм. Ну, знаешь, как буддисты из цветного песка рисуют картины, а потом, когда картина готова, разом сдувают/перемешивают песок. Ну то есть ты будешь несколько дней сидеть ковырять то, что на Go можно за полчаса написать и забыть, и оно будет работать.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Так всё-таки зачем питона мучать? В твоем положении это как раскачивать вагон, надеясь что весь поезд перепрыгнет на соседние, «правильные», рельсы

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

Virtuos86 ★★★★★
()
Ответ на: комментарий от Virtuos86

Так всё-таки зачем питона мучать? В твоем положении это как раскачивать вагон, надеясь что весь поезд перепрыгнет на соседние, «правильные», рельсы

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

Требование обеспечения «простого» метапрограммирования в том числе переусложнило базовые конструкции лиспа, то есть, базовая семантика исполняет ту же роль, которая во многих других языках реализована на низшем уровне — уровне синтаксиса. Примерно как индустрия сменила XML на JSON, так же в девяностые все ринулись упрощать лисп до PHP и питона.

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

Если внимательно присмотреться к диалектам питона, то можно увидеть, что они просто-напросто реализуют подмножество питона. Они не так уж и далеки от питона. Например, мое предложение о новом синтаксисе передачи блоков кода делает ненужными старые лямбды, менеджеры контекстов, list comprehension, и декораторы. Просто херак — и вместо четырех специализированных конструкций одна универсальная. Как натянуть это дело на наследие питона — оч хороший вопрос. Например, как в Unladen Swallow и его наследнике PyPy, делать несколько уровней компиляторов-интерпретаторов.

Но, блин, нужно было годами методично и беспощадно вырезать из языка все кривые фичи и паталогические подходы к кодописанию — вот прямо то, ради чего я начал писать тред. Эдакий аналог «strict mode» из JS. А этого никто не делал 30 лет, хотя бы потому, что язык все эти 30 лет толком никто не поддерживал и не развивал: тут подопрем костылем, здесь подперем, а проблемы решать не будем. Ведь даже в PHP стандартную либу переписывали, но не в питоне.

По-моему, Дзеном питона должно быть «мне похер, это ваша проблема». Если ты посмотришь на все изгибы исторического следа питона, то они идеально подходят под этот лозунг. То есть, медленно работают опреации над матрицами? Мне похер, это ваша проблема — пиши расширения специально для матриц. Криво реализован синтаксис или функция стандартной либы? Мне похер, это ваша проблема — самое смешное то, что ведь интерпретатор не зависел от браузеров, как это было в случае JS. Как реализовать оператор, полиморфным по двум операндам? Мне похер, это ваша проблема. Как реализовать многопоточность? Мне похер, это ваша проблема — делайте ad-hoc на C/C++ или многозадачность, которая ползает еще медленнее (куда еще, казалось бы) чем обычный однозадачный питон.

И вот я вылажу со своей либой для многозадачности в разделяемой памяти, а на меня смотрят как на сумасшедшего: «ты что, не слышал про дзен питона?». Всем похер, а тебе не похер — куда ты прешь против паровоза? Но все же хочется эту карту разыграть. Я получил на неоптимизированных разделяемых структурах данных одну четвертую от производительности заоптимизированного вхлам однопоточного питона. Эти структуры не обязательно должны быть ограничены CPython — можно натянуть их на какой-то диалект или схожий язык. Какой? Я пока что так и не придумал. Вплоть до того, что лепить свой собственный диалект питона, но тогда возникает проблема с готовыми решениями. точнее, их отсутствием. Ух, близко локоток, да не укусишь.

byko3y ★★★★
() автор топика
Последнее исправление: byko3y (всего исправлений: 1)
Ответ на: комментарий от Not_a_Troll

Но, блин, нужно было годами методично и беспощадно вырезать из языка все кривые фичи и паталогические подходы к кодописанию — вот прямо то, ради чего я начал писать тред. Эдакий аналог «strict mode» из JS. А этого никто не делал 30 лет, хотя бы потому, что язык все эти 30 лет толком никто не поддерживал и не развивал: тут подопрем костылем, здесь подперем, а проблемы решать не будем. Ведь даже в PHP стандартную либу переписывали, но не в питоне.

Дебилотред.

Not_a_Troll
()
Ответ на: комментарий от Virtuos86

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

Лисп же, какой еще хахаскиль. Лисп это вечная классика. И практичнее любого ФП задротства.

bread
()
Ответ на: комментарий от byko3y

Например, вспомнить, почему питон уделал лиспа.

Потому что тупая императивщина. Но все-таки динамическая, а значит мозг кодера спасён как от макросов, так и от типизации. Правда потом выяснилось, что типы таки нужны. Может дорастут и до макросов.

bread
()
Ответ на: комментарий от anonymous

@byko3y, желаю вам в Новом Году выбирать инструменты АДЕКВАТНЫЕ для разработки и «борьба» с Ветряными Мельницами ПРЕКРАТИТСЯ …

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

anonymous
()

Есть ли годные гайды по стилю для питона

Шутка

Хорошо мы Питон …ли, надо бы и за другие ЯП посудачить …

anonymous
()
Ответ на: комментарий от byko3y

что никто нигде класс не проверяет

как это никто? Пишут тесты и проверяют.

qaqa ★★
()
Ответ на: комментарий от Not_a_Troll

Долго рожал. Ну, уделыватель LISP. Давай, пофлудим.
Ты Мински когда зырил? А зырил ли вообще?

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

И почему «уделыватель»? Лисп уже давно сам уделался.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Лисп уже давно сам уделался

Лисп, он как Цой — жив, даже если мертв.

Nervous ★★★★★
()
Ответ на: комментарий от bread

Потому что тупая императивщина. Но все-таки динамическая, а значит мозг кодера спасён как от макросов, так и от типизации. Правда потом выяснилось, что типы таки нужны

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

У меня записана цитата с Hacker News, который я когда-то считал обителью технологически продвинутых гуру, а теперь вижу, что это то же сборище хомячков, как и на хабре. Просто, я вырос, а сообщество — нет. Цитата гласила что-то вроде: питону не хватает многопоточности и типизации. Я сделал многопоточность. Дальше чо? А то, что не нужна она. «Завезите в питон типы и потоки» — это наивная и крайне поверхностная фантазия, вроде «если бы бабка была дедом». По сути чел просто хочет из питона сделать жаву, то есть, между строк у цитаты «питону не хватает многопоточности и типизации» можно прочитать «питону для полного счастья нужно стать жавой». Но это бред, потому что жава уже есть, а питон есть такой, какой он есть, и ему нужны совершенно иные инструменты.

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

Если у тебя некоторые аргументы для функции генерируются в строго ограниченном числе функций и на работу этих функций не может повлиять ничего, даже кривые входные параметры, то достаточно разок оттестировать работу функций, и у тебя будет гарантия, что их выхлоп предсказуем. Без типов, заметь, потому что данные и являются своим собственным типом. Как я упоминал выше, V8 реализует именно такой подход, применяя понятие «скрытый класс» — класс, который является уникальным для некой последовательности атрибутов. Однако, даже такой подход не универсален, поскольку в рассмотрение принимаются только атрибуты и порядок их присвоения, а в роли класса также может выступать логические взаимосвязи между значениями атрибутов.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

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

А слабо перевести для детей? Чтобы понятно было? Зценим тебя, как спеца. А то LISP Цой тьфу, мёртв, панимаешь!

Not_a_Troll
()
Ответ на: комментарий от Not_a_Troll

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

А слабо перевести для детей? Чтобы понятно было? Зценим тебя, как спеца. А то LISP Цой тьфу, мёртв, панимаешь!

Нужны гарантии того, что в поле «число детей» не попадет рост в сантиметрах. F# идет по пути типизации, там реально создают целочисленный тип «число детей» и тип «рост в сантиметрах», сложить их нельзя, передать одно вместо другого в функцию тоже. Второй весьма популярный способ сделать аналогичное — это выдавать число детей из одной четко определенной функции, а рост в сантиметрах — из другой. Это подход JS, а такая функция называется конструктором. После этого дело остается за малым — убедиться, что функция достанет из других структур данных именно сантиметры, и вот ты уже получил свою корректность логики.

В каком-то смысле это тоже можно назвать типом, то есть тип «результат_возвращаемый_функциянеймом». Однако, я настаиваю на том, что «результат_возвращаемый_функциянеймом» — это первопричина, а тип — это следствие, один из способов реализации такой проверки. Более того, если ты пишешь на каком-нибудь убогом C и у тебя все целочисленные типы одинаковы, то такие типы намного хуже, чем тип «результат_возвращаемый_функциянеймом». Именно потому я говорю, что вообще-то типов в C нету — там типы являются просто сахаром над арифметикой с указателями.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

F# идет по пути типизации

А ты совсем не в теме? ОК, записали.

Это подход JS

Тут ты тоже по верхам, добавили.

что «результат_возвращаемый_функциянеймом» — это первопричина, а тип — это следствие

Тут совсем печаль. Честно. Я не троллинга ради. Это расстроило меня. Можно вопрос? Ты сейчас клеишь код? Или что-то другого уровня? Хотя… Не надо отвечать, а то я и так пьян, расстроюсь больше.

Not_a_Troll
()
Ответ на: комментарий от byko3y

Если ты можешь достичь тех же гарантий без типов — зачем тебе типы

Типы есть всегда, даже если их явно не указывают. Если программист не думает о типах, то я даже не знаю о чём и чем он думает. Другое дело, что компилятор или среда исполнения должны помогать человеку с определением типов, а не наоборот. В этом смысле, что жаба, что питон совершенно невменяемы. Врукопашную удовлетворять компилятор просто унизительно, не говоря о том, что это ограничивает возможные типы. С другой стороны, рассыпать бесконтрольно нигде не определяемые структурки, как принято (было) в питоне, это ещё хуже.

Без типов, заметь, потому что данные и являются своим собственным типом

То-то и оно. Каждый случайный набор атрибутов порождает тип. Неявно. И как с ним работать никто не знает, пока не найдет в глубинах исходников конкретную строчку, в которой кодер что-то там вернул левой пяткой. А питонщики врут, что у них всё явно. Нет, у них там скрытая жопа повсюду. Даже до недавнего времени не было возможности объявить банальную структуру, т.е. поощрялись плохие практики по неведомым (религиозным что ли) причинам.

bread
()
Ответ на: комментарий от bread

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

Лисп же, какой еще хахаскиль. Лисп это вечная классика. И практичнее любого ФП задротства.

ну, должен же у него быть хоть какой-то плюс, хоть один

Virtuos86 ★★★★★
()
Ответ на: комментарий от byko3y

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

Virtuos86 ★★★★★
()
Ответ на: комментарий от byko3y

. F# идет по пути типизации, там реально создают целочисленный тип «число детей» и тип «рост в сантиметрах», сложить их нельзя, передать одно вместо другого в функцию тоже.

В Python коммунизм.
Все жены, типы, …

ОБЩИЕ!
anonymous
()
Ответ на: комментарий от anonymous

Эх робяты, ШАС СПОЮ!

Товарищи C++-ники! Питонщики с кандидатами!
Замучились вы с классами, запутались в ООП!
Сидите, разлагаете ЯП на атомы,
Забыв, что разлагается картофель на полях.

Из Метапрог и плесени бальзам извлечь пытаетесь
И флудите на форуме по десять раз на дню.
Ох, вы там добалуетесь! Ох, вы доизвлекаетесь,
Пока сгниет, заплесневет картофель на корню!

Автобусом до Сходни доезжаем,
А там - рысцой, и не стонать!
Небось картошку все мы уважаем,
Когда с сольцой ее намять!

Вы можете прославиться почти на всю Европу, коль
С лопатами проявите здесь свой патриотизм.
А то вы всем кагалом там набросились на ООП,
ЯП ножами режете, а это - бандитизм.

Товарищи ЛОР-вцы, Эйнштейны драгоценные,
Ньютоны ненаглядные, любимые до слез!
Ведь лягут в землю общую остатки наши бренные,
Земле - ей все едино: апатиты и навоз.

Товарищи ЛОР-вцы! Не сумневайтесь, милые:
Коль что у вас не ладится - ну, там, не тот aффект, -
Мы мигом к вам заявимся с Метапрогом и с вилами,
Денечек покумекаем - и выправим дефект. 
anonymous
()
Ответ на: комментарий от Not_a_Troll

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

anonymous
()
Ответ на: комментарий от anonymous

Поздравляю с наступающим Новым Годом

Линуксоидов, Андропоидов, Виндопоидов и иных товарищей! ...
anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.