The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]




Версия для распечатки Пред. тема | След. тема
Новые ответы [ Отслеживать ]
Perl или Python кого изучать?, !*! JWalker, 03-Дек-08, 15:21  [смотреть все]
  • Perl или Python кого изучать?, !*! phpcoder, 15:29 , 03-Дек-08 (1)
  • Perl или Python кого изучать?, !*! NuINu, 15:30 , 03-Дек-08 (2)
  • Perl или Python кого изучать?, !*! Pikador, 15:44 , 03-Дек-08 (3)
  • Perl или Python кого изучать?, !*! angra, 16:26 , 03-Дек-08 (4)
  • Perl или Python кого изучать?, !*! Pikador, 17:55 , 03-Дек-08 (6)
  • Perl или Python кого изучать?, !*! Аноним, 18:34 , 03-Дек-08 (7)
    • кого, !*! Andrey Mitrofanov, 11:25 , 04-Дек-08 (14)
      • кого, !*! Аноним, 16:56 , 05-Дек-08 (18)
  • Perl или Python кого изучать?, !*! Square, 18:48 , 03-Дек-08 (8)
  • Perl или Python кого изучать?, !*! NuINu, 22:38 , 03-Дек-08 (11)
    • Perl или Python кого изучать?, !*! BigHo, 20:05 , 12-Дек-08 (23)
      >питон он такой абстрактно вылизанный, что бы скрыть от разработчика особенности архитектуры.

      согласен. Хотя там такие особенности, что можно было бы и не скрывать - ого-го! Всем бы такие. Только тогда это будут не особенности. Кстати, вы о чем именно?

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

      интересно (дайте позырить бред...), но без ссылки - как без рук.

      >IPC на нем ни к черту.

      угу, IPC только на изначально паралеллуемых языках (типа Erlang) - в удовольствие. Сравнивать же python неизвестно какую реализацию с непонятно чем в perl-е - место для холивора, в котором вы уже выбрали выигрышную позицию (по крайней мере - безпроигрышную).

      >фишка с необязательным определеним переменных приводит к больше'му количеству невыявленных в тестах
      >ошибок.

      Хорошо сравнивать perl с включенным "use strict". Без него всплыло бы точно такое же бревно. Хочется типизированности для python - Cython (http://pypi.python.org/pypi/Cython/) и не только он. Не хочется python-а вообще - есть много других симпатичных скриптовых языков. Поиск среди них займет значительную часть времени, но по поводу удобства читать/писать - python и js на первых местах. Перл больше подходит для тех, кто "я не читатель, я - писатель" - сделал раз, и забыл. Чтобы понятно писать на perl-е приходится придерживаться правила отступа, характерного для питона.

      >перловая фишка с $ @ % реально помогает читать код.

      Даа-а-а, без них перл перестал бы быть перлом, а стал, ну скажем, стhашненькой javascript. Разделение наименования переменных по признаку типа делается неспроста, но я так и не понял - зачем именно. Чтобы слиться с переменной, почувствовать себя единым целым и выстрелить код? Может уже открыты и другие пути для медитации?

      >CPANа для питона нет.

      Нету. Зачем python-у - перловские библиотеки? Зато есть easy_install. Или точно нужен именно CPAN?

      >недавно смотрел систему мониторинга сетей zenoss на питоне, фишка в том что
      >можно писать собственные обработчики событий прямо с веб интерфейса. но питон
      >то для этого не предназначен, ему очень важно пробельное форматирование, в
      >результае код мягко говоря "почему то" неработал.

      Раз уж в языке пробел играет синтаксическую роль, то нелепо их игнорировать, и писать слова слитно. А проблема zenoss (точно такая есть и её еще не исправили?), это всего лишь проблема самого zenoss.

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

      Вообщем, не буду рекомендовать никакой язык, абы просто защитить свой взгляд на вещи. Идеального языка не существует, иначе мы уже давно ни о чем не спорили бы. Все решения лучше пробовать под себя лично, не доверяя даже другу (друзья иногда такого могут отмочить, особенно первого апреля). Хотя нет, все же порекомендую - попрактиковать brainfuck (http://en.wikipedia.org/wiki/Brainfuck) - любой сразу же изученный после него язык становится мечтой всей жизни ;)

      • Perl или Python кого изучать?, !*! NuINu, 00:22 , 13-Дек-08 (25)
        • Perl или Python кого изучать?, !*! BigHo, 16:38 , 13-Дек-08 (26)
          >о слеше :) os.path.join

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

          >перенаправление вывода на питоне: http://www.opennet.me/openforum/vsluhforumID9/7540.html
          >как сделать по другому я не нашел.

          В принципе решение - верное. Я бы все же сделал это через os.popen (их там несколько popen, popen2, popen3, popen4). Если уж непременн нужно _напрямую_ свалить стандартный вывод в файл, то это была бы последовательность fork -> open -> dup (или dup2) -> execl (или другие из exec* семейства). Еще проще - задать вывод в самом system сценарии - ведь для исполнения аргумента вызывается интерпретатор:

          os.system("%s > t2.log" % ("cat redir_stdout.py",))

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

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

          У меня xml код тоже не проходит через jabber. Да и другой код вместо того чтобы пройти нормально начинает рисовать "рожицы" - подмаргивать, улыбаться, или наоборот - грустить. И вроде бы все это далеко не python.

          >то не проблема зеноса. то просто неудобство редактора в веб браузере, но
          >происходит она(как я считаю) именно из за синаксиса питона.

          Насчет отступов блоков питона - есть такой язык, о котором достаточно мало известно. Называется "Дракон" (разработка оборонки советского союза). Большей частью он напоминает блоксхемы. На нем в свое время разрабатывалось ПО и велась алгоритмизация аппаратных решений для проекта "Буран". Что самое интересное, подход к блоксхемам частично напоминает тот же подход, что и в питоне. Поищите в гугл "дракон язык программирования буран". Если приглядеться, то там масса отличий. Тем не менее стремление языка к двумерному отображению схемы вместо лапши увеличивает его наглядность. Кстати, картинка на вики - это юмористический эскиз, с техническими огрехами. Для интересующихся из литературы могу предложить почитать книжку "Как улучшить работу ума". По ней в свое время разработал надстройку для dia, чтобы можно было рисовать блок-схемы, но удобства без автоматической компановки оказалось очень мало. На питон с тех пор взглянул под несколько другим углом.

        • Perl или Python кого изучать?, !*! camel, 12:52 , 15-Дек-08 (27)
        • Perl или Python кого изучать?, !*! 0dmin, 21:10 , 15-Дек-08 (29)
          • Perl или Python кого изучать?, !*! NuINu, 22:15 , 15-Дек-08 (30)
            • Perl или Python кого изучать?, !*! BigHo, 12:26 , 16-Дек-08 (31)

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

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

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

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

              Может быть "один писатель" и "множество читателей" реализуется более просто - разделяемая память не единственный метод. Почему вы пошли именно этим путем? Или это только пример?

              • Perl или Python кого изучать?, !*! NuINu, 14:01 , 16-Дек-08 (32)
                • Perl или Python кого изучать?, !*! BigHo, 16:08 , 16-Дек-08 (33)
                  >>Именно для данной задачи лучше не перенаправлять стандартные выводы, а считывать через
                  >>popen функции: если есть вывод - открывать лог-файл, блокировать его эксклюзивной
                  >
                  >пробема в том что вы можете в своем проекте использовать кучу сторонних
                  >библиотек, и врядли каждый вызов в своей программе вы будете реализовывать
                  >через сторонний процесс.
                  >а в силу этого и нужно переопределение стдаута в основном процессе.

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

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

                  тесты вам бы доказали, что не намного медленней. Выигрыш не будет заметен для буферов малой протяженности: 1-2% - это не то, ради чего стоит жертвовать стабильностью программ. Конечно, есть еще интересное решение virtual ring buffer (в тему уменьшения количества операций копирования в режиме пользователя), но это уже о разделяемой памяти для одного процесса.

                  >если использовать триды то эквивалентно по скорости. но в данном случае я
                  >предлагал реализовывать взаимодействие между процессами.

                  Да. Прошу все же заметить, что разделение памяти несколько отличается стабильностью в худшую сторону по сравнению с другими IPC методами. Обычно разделение на процессы делают тогда, когда хотят большей защищенности адресного пространства. pthread_mutex_* не смогут защитить, если один из процессов выйдет, забыв разлочить ранее заблокированный замок. В этом случае нет разницы: что используешь многопоточность, что разделяемую память - грабли, по конфигурации набитой шишки похожи, как близнецы.

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

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

                  • Perl или Python кого изучать?, !*! NuINu, 16:55 , 16-Дек-08 (34)
                    • Perl или Python кого изучать?, !*! BigHo, 18:12 , 16-Дек-08 (38)
                      >ооо!!! ужас! как вы только живы? или страдают только сторонние разработчики? :)

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

                      >да да путаете, я про mmap ничего не говорил это своершенно другая
                      >область. эта вещь не предназначена для межпроцессного взаимодействия(вернее не предназначена только
                      >для него) хотя как я понимаю используется именно для него. ну
                      >не суть.
                      >
                      >я говорил про функции shmget/shmat/shmdt при этом при самой передаче данных ни
                      >одна из них не вызывается. т.е процесс происходит без участия ядра(кончено
                      >вызываются функции блокировки)

                      Функции mmap семейства и shm* семейства не одинаковы, суть же их одна. Поэтому то, что было сказано для mmap - характерно и для shm*.

                      Проще всего их рассматривать как интерфейс к ядру ОС по распределению оперативной памяти. Обращение за памятью через mmap и через shmat вызывает схожие процессы в ядре, и уж совершенно точно - используют одну и ту же архитектуру работы с виртуальными страницами. Речь идет не только про AMD64 eXecute и Read/Write биты, но и про указатели на листы памяти, которые хранятся совместно с этими битами.

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

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

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

  • Perl или Python кого изучать?, !*! rasmon, 16:58 , 16-Дек-08 (35)



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру