Перенос кода Perl на Python

> пример я выше привел в тегах [ code ]

Это не пример, а невнятное нытье.

что же тебе еще остается? ляпнул про компиляцию и все примеры противоречащие твоему ляпу объявлять унылыми.

продолжай

> что же тебе еще остается? ляпнул про компиляцию и все примеры противоречащие твоему ляпу объявлять унылыми.

Ты пока ни единого примера не привел. То, что было в тегах «code», не в счет - в чем там ошибка, знает только твое подсознание.

если открываем в редакторе настроенном ts=4, то видим такой код

for цикл:
       if условие:
            действие1
<tab>  действие2

в реале (для компилятора) код такой:

for цикл:
       if условие:
            действие1
 <tab>      действие2

код будет компилироваться. будет компилироваться и в случае если редактор заменит <tab> на соответствующее число пробелов.

вот только видит программист один алгоритм, а компилятор видит другой алгоритм.

выходов тут только два: в каждом файле описывать настройки редактора для ручной установки, либо прописывание modeline.

сам язык не в силах отгадать что действие2 нужно выполнять в теле цикла, а не ветке if

> если открываем в редакторе настроенном ts=4, то видим такой код

То есть в коде отступы делаются пробелами, один уровень отступов - 8 пробелов (спрашиваю, потому что в [code] у тебя отступы разные), но мы открываем код с ts=4 и делаем отступ табом (двумя табами, чтобы получить ошибку, о которой ты говоришь)?

То есть в коде отступы делаются пробелами, один уровень отступов - 8 пробелов (спрашиваю, потому что в

 у тебя отступы разные), но мы открываем код с ts=4 и делаем отступ табом (двумя табами, чтобы получить ошибку, о которой ты говоришь)? [/quote]

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

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

поскольку на уровне языка вообще нет указаний какой размер таба, то получается что перенастраивать редактор я себе не моги. соответственно протрахавшись в поисках новых багов я в итоге выставил себе для питоновских файлов ts=8 раз и навсегда.

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

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

Обычно мейнтенер пакета на Питоне имеет какой-то опыт программирования на Питоне. И он не станет намеренно стрелять себе в ногу (твой сценарий - это именно намеренная стрельба).

я в итоге выставил себе для питоновских файлов ts=8 раз и навсегда.

Одно из возможных решений. А то, как табы заменяются на пробелы, описано в определении языка, пункт 2.8.1 в моем Python Reference Manual.

Обычно мейнтенер пакета на Питоне имеет какой-то опыт программирования на Питоне. И он не станет намеренно стрелять себе в ногу (твой сценарий - это именно намеренная стрельба).

это не намеренная стрельба. я имею несколько собственных проектов на питоне. в этих проектах сквозняком проходит одна настройка ts/et. когда я беру чужой проект, там проходит другая настройка ts/et. и внутриязыкового механизма сопряжения этих вещей нет.

Отступы --- самое распространённая и самая дурацкая претензия к Питону. Следующая по безумности и одновременно по популярности --- GIL.

Отступы --- самое распространённая и самая дурацкая претензия к Питону.

дык отступы — самая глупая вещь в питоне.

> дык отступы — самая глупая вещь в питоне.

Она, может, и глупая, но не вызывает проблем. По крайней мере, не настолько, чтобы быть претензией #1.

Отступы --- самое распространённая и самая дурацкая претензия к Питону.

дык отступы — самая глупая вещь в питоне.

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

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

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

(nil t). Они знали, и написали две разных реализации, не? В этом и заключалась процедура «приведения к общему знаменателю» (с потерей части функционала kqueue, как я могу предположить с высоты моих незначительных познаний).

А не так весело учредили, как ты в посте 32, ибо у epoll и kqueue методы, блин, разные.

И вообще, ты только что написал три либы для C(++). Их никак нельзя назвать изкоробочными, t? Так почему ты жалуешься на отсутствие изкоробочности в питоне? Обёртку к libevent в зубы и вперёд!

ну разные и чего? _принципиального_ различия между ними нет, поэтому и возможно это приведение к общему знаменателю

Достаточно посмотреть стиль табов в коде (если поделка хоть сколько-нить стоящая, то он будет единый) и быстро, решительно перенастроить редактор. В виме это три-четыре опции (или даже одна, expandtab).

А вообще за все фокусы с индентом, не соответствующие PEP 8, нужно убивать табуреткой в висок.

Ну, приятные дополнительные фичи, которые отличают их от poll - это принципиальное различие? Хотя множества этих фич пересекаются, но не совпадают.

И вообще речь шла про то, что в питоне из коробки не обернули абстракцию. Дык её нигде не обернули! НапишиСкачай и пользуйся.

Какие фичи? epoll/kqueue используют не из-за фич, а из-за алгоритма O(1). На каждой итерации event-loop'а в poll/select надо передавать все сокеты заново, а в epoll/kqueue не надо. select еще имеет ограничение на 1024 сокета. Вот и все различие.

Да, kqueue конечно еще может за файлами следить, в этом функционале он идентичен inotify, поэтому тут можно kqueue и inotify привести к общему знаменателю.