форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Программирование под UNIX (Public)
Изначальное сообщение		[ Отслеживать ]

"Perl или Python кого изучать?"

Сообщение от JWalker (ok) on 03-Дек-08, 15:21

Здравствуйте. Появилось желание\необходимость (на самом деле - и то, и другое) изучить какой-нибудь язык широкого профиля. Раньше (лет 7 назад) кодил на Delphi, но надоело, и я стал сисадмином. Так вот, посидел я, поглядел...И даже не знаю, за что взяться: Python -вроде интересный, читабельный, современный и все на нем можно (от игр и до админских сценариев), Perl - непонятный (даже мистический что-ли), с историей, философией, как я понял, смахивает на шелл-скрипты на стероидах, однако, теряет популярность для вэба и т.д (хотя, вроде, некоторые ждут свежую версию)...Подскажите, кто из них двоих полезнее\перспективнее для админа, который может и покодить иногда (для себя\для других)? Или я упустил какой-то другой язык, на который стоило бы обратить внимание?

Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Perl или Python кого изучать?"

Сообщение от phpcoder (??) on 03-Дек-08, 15:29

Python IMHO.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Perl или Python кого изучать?"

Сообщение от NuINu (??) on 03-Дек-08, 15:30

>[оверквотинг удален] >какой-нибудь язык широкого профиля. Раньше (лет 7 назад) кодил на Delphi, >но надоело, и я стал сисадмином. Так вот, посидел я, поглядел...И >даже не знаю, за что взяться: Python -вроде интересный, читабельный, современный >и все на нем можно (от игр и до админских сценариев), >Perl - непонятный (даже мистический что-ли), с историей, философией, как я >понял, смахивает на шелл-скрипты на стероидах, однако, теряет популярность для вэба >и т.д (хотя, вроде, некоторые ждут свежую версию)...Подскажите, кто из них >двоих полезнее\перспективнее для админа, который может и покодить иногда (для себя\для >других)? Или я упустил какой-то другой язык, на который стоило бы >обратить внимание? обрати внимание на си. еще вариант изучить и перл и питон.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "Perl или Python кого изучать?"

Сообщение от Pikador (ok) on 03-Дек-08, 15:44

Python рулит!

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "Perl или Python кого изучать?"

Сообщение от angra (ok) on 03-Дек-08, 16:26

Перл значительно интересней питона, при желании может быть более читабельным, на нем можно тоже делать все что угодно, у него огромная библиотека. Ну а по поводу несовременности, лучше глянуть на С, языку почти сорок лет, а уходить на свалку он не спешит. Тоже и с перлом. По поводу философии. Питон исповедует два принципа 1) все является объектами 2) есть только один способ(синтаксис) сделать какое-либо елементарное действие. Перл не ограничивает программиста, вы можете работать в процедурном, объектном и даже частично функциональном стиле. Для большинства елементарных действий есть более чем один способ(синтаксис). Все это приводит к любопытному выводу: на перле очень приятно писать, но тяжело читать написанное другими, если они придерживаются другого стиля. На питоне почти наоборот. Для админа однозначный выбор - Perl. Это не просто шелл на стероидах, это универсальный инструмент админа заменяющий шелл, awk, sed, grep итд. В отличие от питона он изначально создавался для администрирования и однострочники(и даже небольшие скрипты) на нем во много раз изящней и короче. Кроме того перл стандарт де-факто в никсах, минимальный его вариант легче найти, чем нужную версию перечисленных выше утилит, как следствие проще выучить его, чем кучу вариаций синтаксиса других утилит.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	5. "Perl или Python кого изучать?"
	Сообщение от Pahanivo (ok) on 03-Дек-08, 16:49
	>[оверквотинг удален] >писать, но тяжело читать написанное другими, если они придерживаются другого стиля. >На питоне почти наоборот. > >Для админа однозначный выбор - Perl. Это не просто шелл на стероидах, >это универсальный инструмент админа заменяющий шелл, awk, sed, grep итд. В >отличие от питона он изначально создавался для администрирования и однострочники(и даже >небольшие скрипты) на нем во много раз изящней и короче. Кроме >того перл стандарт де-факто в никсах, минимальный его вариант легче найти, >чем нужную версию перечисленных выше утилит, как следствие проще выучить его, >чем кучу вариаций синтаксиса других утилит. вах дарагой! ты забыл сказать что у perl самый крутые regex ) с точки зрения удобности использования - однозначно perl - он практически везде стоит. В случае необзодимости функционал допинывается модулями.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	9. "Perl или Python кого изучать?"
	Сообщение от Стремительный Домкрат on 03-Дек-08, 22:22
	Эх Angra ... >Перл значительно интересней питона, при желании может быть более читабельным,   1) Грузины интересней чем армяне! Чем?! ... Не напомнило? 2) Теоретически перл может быть читаемым. Практически за последние 12 лет видел только пяток читаемых программ :( >на нем можно тоже делать все что угодно, у него огромная библиотека. Ну драйвера к примеру особо не попишешь :) Но в application domain - да. >По поводу философии. Питон исповедует два принципа >1) все является объектами Но при этом в Питоне не всё является объектом :) >2) есть только один способ(синтаксис) сделать какое-либо элементарное действие. Java делает то же самое - в результате самый популярный язык для Ъ Ынтрыпрайз (тот самый application domain). >Перл не ограничивает программиста, вы можете работать в процедурном, >объектном и даже частично функциональном стиле. А Питон - ограничивает! Там нет ни процедур, ни объектов ни функциональщины?! Да что с тобой Angra? Вещаешь как PR-щик ... >на перле очень приятно писать, но тяжело читать написанное другими, >На питоне почти наоборот. Не заметил что на питоне писать неприятно. Ну это слишком личное чтобы хоть как то измерить. >Для админа однозначный выбор - Perl. В 1994 году - согласился бы не задумываясь! Сейчас - не смеши :) _однозначного_ выбора уже нет, есть куча примерно равных вариантов. Но чем взрослее становится истинный UNIX-admin тем сильнее он понимает что только sh - "наше всьЁ"! >Это не просто шелл на стероидах, это универсальный инструмент >админа заменяющий шелл, awk, sed, grep итд. Напуркуа их _заменять_ ? К примеру - все они есть в busybox'е, а вот взгромоздишь ли ты полноценный перл на openWRT? Вряд ли. Ну и "у них вЭй!" ... >В отличие от питона он изначально создавался для администрирования Это Practical Extraction and Report Language то? :) "Perl was originally developed by Larry Wall, as a general purpose Unix scripting language to make report processing easier."(С)педивикия >и однострочники(и даже небольшие скрипты) на нем во много раз изящней и короче. О - да! Я помню изящный скриптик на 5-10 строчек опубликованный на ЛОР'е - типо "помогите разобраться - не печатает" и сколько наивных его запустило ;-D >Кроме того перл стандарт де-факто в никсах, Все ведущие линуксы имеют питон "из коробки" тоже. Да и юзается он в них по самое "не балуй". >минимальный его вариант легче найти, Минимальный - не нужен, см. openWRT (справедливости ради - минимальный питон так же не нужен - см. нокию). А полноценный питон работает на всём где работает перл. Подытожим всё вышесказанное - для чего я всё это тут писал? Чтобы обосрать перл? - Нет! Чтобы возвысить питон? - Нет! Чтобы донести простую мысль - сейчас не 1994, в богатые времена живём! Поэтому выбор есть всегда. И пожалуй настало время когда можно выбирать по принципу - вот это нравится лично мне, даже объяснить не могу почему ... и это будет работать :) Топикстареру - выбери 5-10 типичных для тебя задачек и порешай их на перле, питоне, шелле, браинфаке и на всём что интересно. И постепенно поймешь с чем ты хочешь работать - это и будет _твой_ выбор :) PS: А потом ты радостный придешь на работу чтобы доложить начальству о своём выборе и получишь люлей потому что разрешен только sh, C and Java ... :) Проза жизни мать её. PPS: Подписываться не буду - я обычно такие огромные посты не пишу ... слегка стыдственно :) А посему - Ваш, Стремительный Домкрат.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	12. "Perl или Python кого изучать?"
	Сообщение от JWalker (ok) on 04-Дек-08, 01:32
	Спасибо, очень спасибо за такой большой и толстый пост. Правда, у меня теперь появилось ощущение что я что-то неправильное в топике спросил =)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	15. "Perl или Python кого изучать?"
	Сообщение от madskull (??) on 04-Дек-08, 12:30
	>Спасибо, очень спасибо за такой большой и толстый пост. Правда, у меня >теперь появилось ощущение что я что-то неправильное в топике спросил =) > Ну как сказать... Под разжигание классовой ненависти это не подпадает, конечно. Но, как и следовало ожидать, холиваром потянуло...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	16. "Perl или Python кого изучать?"
	Сообщение от JWalker (ok) on 04-Дек-08, 19:37
	Как раз новости о перле и питоне на главной
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	13. "Perl или Python кого изучать?"
	Сообщение от Pikador (ok) on 04-Дек-08, 10:52
	>В 1994 году - согласился бы не задумываясь! Сейчас - не смеши >:) _однозначного_ выбора уже нет, есть куча примерно равных вариантов. Но >чем взрослее становится истинный UNIX-admin тем сильнее он понимает что только >sh - "наше всьЁ"! > Точно. Все писал только на shell, в том числе cgi и web-сервисы. Прекрасно обхожусь без досконального знания perl. Понравился питон, стал дополнительно писать на том, что нравится. При всем уважении к перлу, питон ИМХО интереснее.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "Perl или Python кого изучать?"

Сообщение от Pikador (ok) on 03-Дек-08, 17:55

http://www.python.org/dev/peps/pep-0020/ Есть ли что-то подобное у Perl ?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	10. "Perl или Python кого изучать?"
	Сообщение от NuINu (??) on 03-Дек-08, 22:28
	>http://www.python.org/dev/peps/pep-0020/ >Есть ли что-то подобное у Perl ? дзен он и в африк дзен.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "Perl или Python кого изучать?"

Сообщение от Аноним (??) on 03-Дек-08, 18:34

Для админа лучше Perl, потому что на нем можно коротко писать сложные вещи, опять же встроенные regexp'ы и CPAN, в котором есть вообще все что душа пожелает. Нечитабельность Perl это миф. Про `шелл-скрипты на стероидах' какая-то бредятина. А в целом я считаю имеет смысл знать оба языка, ибо у python есть свои плюсы.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	14. "кого"
	Сообщение от Andrey Mitrofanov on 04-Дек-08, 11:25
	>А в целом я считаю имеет смысл знать оба языка, ибо у python есть свои плюсы. Вот что-то в этом есть. Только %) не могу понять что. Как выучивний и использующий bash+[некоторые] ***utils+немного sed + [кое-где мно-о-о-го] gawk и "ниасиливший"/поленившийся/испугавшийся и perl, и python, :) скажу -- сценарии/скрипты (администрирование, да?) и командная строка - это, конечно, шелл (и bash, в частности, как одна из реализаций). А "язык программирования" - это другой уровень сложности, вероятно, не необходимый для "простых" задач. "Языка широкого профиля", как-то на горизонте не видно. Одного, по крайней мере. Их почему-то много и разных. Складывается впечатление, что для каждогоо из них может существоаать круг "наиболее подходящих" задач... Кстати, этот круг кроме всего ешё и субъективен: опыт работы с языком и практического/успешного использования в частности для конкретного направления/задачи повышает его, языка, пригодность для решения подобных задач -- конкретным индивидом. %) Поэтому кто-то скажет, что perl - самое оно для веб-програмирования, кто-то - для обработки текстов (регэкспами), кто-то вспомнит системные сценарии, и т.д. Другие расскажут (если предположить достаточную широту "опроса") о своих _впечатлениях_ от python-а, bash-а, awk-а, lisp-а/scheme-ы, ruby.... Андрей,,), под впечатлением от TAOUP ESR-а  http://www.williamspublishing.com/Books/5-8459-0791-8.html и изучающий на новенького rails и ruby _для_ них.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	18. "кого"
	Сообщение от Аноним (??) on 05-Дек-08, 16:56
	>>А в целом я считаю имеет смысл знать оба языка, ибо у python есть свои плюсы. >Вот что-то в этом есть. Только %) не могу понять что. >Как выучивний и использующий bash+[некоторые] ***utils+немного sed + [кое-где мно-о-о-го] gawk и >"ниасиливший"/поленившийся/испугавшийся и perl, и python, :) скажу -- сценарии/скрипты (администрирование, да?) >и командная строка - это, конечно, шелл (и bash, в частности, >как одна из реализаций). А "язык программирования" - это другой уровень >сложности, вероятно, не необходимый для "простых" задач. Я вижу три 3 уровня: на первом (для решения большинства задач администрирования), разумеется, sh на втором, где нужна более сложная обработка данных и более хитрая логика - perl. Там и встроенные regexp'ы, и удобные структуры данных и мощнейший синтаксис, на котором можно писать нетривиальные вещи коротко и понятно. на третьем - python, это уже ближе к прикладухе, ибо там и py-qt, и pygame и прочее - на нем уже можно писать полноценные end-user приложения. >"Языка широкого профиля", как-то на горизонте не видно. Одного, по крайней мере. >Их почему-то много и разных. Складывается впечатление, что для каждогоо из >них может существоаать круг "наиболее подходящих" задач... Кстати, этот круг кроме >всего ешё и субъективен: опыт работы с языком и практического/успешного использования >в частности для конкретного направления/задачи повышает его, языка, пригодность для решения >подобных задач -- конкретным индивидом. %) Поэтому кто-то скажет, что perl Разумеется.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

8. "Perl или Python кого изучать?"

Сообщение от Square (ok) on 03-Дек-08, 18:48

>[оверквотинг удален] >какой-нибудь язык широкого профиля. Раньше (лет 7 назад) кодил на Delphi, >но надоело, и я стал сисадмином. Так вот, посидел я, поглядел...И >даже не знаю, за что взяться: Python -вроде интересный, читабельный, современный >и все на нем можно (от игр и до админских сценариев), >Perl - непонятный (даже мистический что-ли), с историей, философией, как я >понял, смахивает на шелл-скрипты на стероидах, однако, теряет популярность для вэба >и т.д (хотя, вроде, некоторые ждут свежую версию)...Подскажите, кто из них >двоих полезнее\перспективнее для админа, который может и покодить иногда (для себя\для >других)? Или я упустил какой-то другой язык, на который стоило бы >обратить внимание? для системного администратора - однозначно perl. плюс широчайший спектр применений - позволяет делать абсолютно все что угодно.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

11. "Perl или Python кого изучать?"

Сообщение от NuINu (??) on 03-Дек-08, 22:38

я хоть и изучил питон, и даже несколько приложений написал. игрушковых. но все таки как доходит до реально работающих, для работы, все равно на перл сваливаюсь. питон он такой абстрактно вылизанный, что бы скрыть от разработчика особенности архитектуры. посему системные приложения на нем крайне неудобно писать. тут на конфе я как то приводил пример как переоределить стандартные потоки ввода вывода на питоне, посмотрите кому интересно - полный бред! IPC на нем ни к черту. фишка с необязательным определеним переменных приводит к больше'му количеству невыявленных в тестах ошибок. перловая фишка с $ @ % реально помогает читать код. CPANа для питона нет. недавно смотрел систему мониторинга сетей zenoss на питоне, фишка в том что можно писать собственные обработчики событий прямо с веб интерфейса. но питон то для этого не предназначен, ему очень важно пробельное форматирование, в результае код мягко говоря "почему то" неработал. хотя кому нравиться... ради бога. на нем сделаны реально интересные вещи.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	23. "Perl или Python кого изучать?"
	Сообщение от BigHo on 12-Дек-08, 20:05
	>питон он такой абстрактно вылизанный, что бы скрыть от разработчика особенности архитектуры. согласен. Хотя там такие особенности, что можно было бы и не скрывать - ого-го! Всем бы такие. Только тогда это будут не особенности. Кстати, вы о чем именно? >посему системные приложения на нем крайне неудобно писать. >тут на конфе я как то приводил пример как переоределить стандартные потоки >ввода вывода на питоне, посмотрите кому интересно - полный бред! интересно (дайте позырить бред...), но без ссылки - как без рук. >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) - любой сразу же изученный после него язык становится мечтой всей жизни ;)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	25. "Perl или Python кого изучать?"
	Сообщение от NuINu (??) on 13-Дек-08, 00:22
	>Кстати, вы о чем именно? о слеше :) os.path.join перенаправление вывода на питоне: http://www.opennet.ru/openforum/vsluhforumID9/7540.html как сделать по другому я не нашел. правила отступа характерны не только для питона, они характерны для хорошо написанного кода. если человек не сможет их осилить, то и питонвский синтаксис ему не поможет. а обмениваться примерами кода, к примеру через аську или джабер конфу не удобно. весь код "сползает". то не проблема зеноса. то просто неудобство редактора в веб браузере, но происходит она(как я считаю) именно из за синаксиса питона.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	26. "Perl или Python кого изучать?"
	Сообщение от BigHo on 13-Дек-08, 16:38
	>о слеше :) os.path.join Думаю, что это как раз необходимая степень абстракции, для работы с файловой системой на различных ОС. В итоге на выходе получаем строку с именем файла. Это, кстати, не вшито намертво на нижнем уровне, а написано на чистом питоне. Если что-то не устраивает, можно переписать так, как нужно. Во всяком случае у меня к этому претензий как раз и не было. >перенаправление вывода на питоне: http://www.opennet.ru/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, чтобы можно было рисовать блок-схемы, но удобства без автоматической компановки оказалось очень мало. На питон с тех пор взглянул под несколько другим углом.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	27. "Perl или Python кого изучать?"
	Сообщение от camel on 15-Дек-08, 12:52
	>перенаправление вывода на питоне: http://www.opennet.ru/openforum/vsluhforumID9/7540.html >как сделать по другому я не нашел. то, что там написано - это полный... не, не так. так пишут на Perl-е. В Python это не прокатывает.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	28. "Perl или Python кого изучать?"
	Сообщение от NuINu (??) on 15-Дек-08, 20:57
	>>перенаправление вывода на питоне: http://www.opennet.ru/openforum/vsluhforumID9/7540.html >>как сделать по другому я не нашел. > >то, что там написано - это полный... не, не так. >так пишут на Perl-е. В Python это не прокатывает. почему же не прокатывает? у меня данный код работает. расскажите тогда как прокатывает.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	29. "Perl или Python кого изучать?"
	Сообщение от 0dmin on 15-Дек-08, 21:10
	>перенаправление вывода на питоне: http://www.opennet.ru/openforum/vsluhforumID9/7540.html >как сделать по другому я не нашел. Дык еще бы - особенно если и не искал :) А вообще - да АЦЦки трудно: # Взято из "Букваря" import sys print 'Dive in' saveout = sys.stdout fsock = open('out.log', 'w') sys.stdout = fsock print 'This message will be logged instead of displayed' sys.stdout = saveout fsock.close() Или вот так (передай чуваку с вопросом по ссылке): он хотел (говоря shell'ом): output=`mycmd myarg` говоря питоном это: import subprocess output = Popen(["mycmd", "myarg"], stdout=PIPE).communicate()[0] Я ж говорил - АЦЦки трудно и нечитаемо.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	30. "Perl или Python кого изучать?"
	Сообщение от NuINu (??) on 15-Дек-08, 22:15
	>[оверквотинг удален] >Дык еще бы - особенно если и не искал :) А вообще >- да АЦЦки трудно: > ># Взято из "Букваря" >import sys >print 'Dive in' >saveout = sys.stdout >fsock = open('out.log', 'w') >sys.stdout = fsock >print 'This message will be logged instead of displayed' хоршо, а что будет если мы здесь вызовем os.system('ls /') кудай пойдет вывод? >[оверквотинг удален] >fsock.close() > > >Или вот так (передай чуваку с вопросом по ссылке): >он хотел (говоря shell'ом): output=`mycmd myarg` >говоря питоном это: >import subprocess >output = Popen(["mycmd", "myarg"], stdout=PIPE).communicate()[0] > >Я ж говорил - АЦЦки трудно и нечитаемо. хорошо, но я на самом деле решал немного другую задачу(вне зависимости от заданного вопроса) как перенаправить любой вывод, даже самый неожиданный. для чего? в контексте разработки CGI приложений. когда ты используешь кучу сторонних библиотек. и любая из них, в случае ошибки, может выдать с stdout очень неприятную запись, что очень нехорошо с точки зрения безопасности. ну а то что вы привели это лишь один из IPC, надо заметить самый простой, попробуйте на питоне сделать работу с разделяемой памятью и блокировкой. к примеру для алгоритма один писатель множестов читателей. ваши друзья питонисты скажут вам спасибо.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	31. "Perl или Python кого изучать?"
	Сообщение от BigHo on 16-Дек-08, 12:26
	>хорошо, но я на самом деле решал немного другую задачу(вне зависимости от >заданного вопроса) как перенаправить любой вывод, даже самый неожиданный. >для чего? в контексте разработки CGI приложений. когда ты используешь кучу сторонних >библиотек. и любая из них, в случае ошибки, может выдать с >stdout очень неприятную запись, что очень нехорошо с точки зрения безопасности. Именно для данной задачи лучше не перенаправлять стандартные выводы, а считывать через popen функции: если есть вывод - открывать лог-файл, блокировать его эксклюзивной блокировкой (fcntl), записывать таймстемп, информацию о вызывающем скрипте, и информацию из стандарного вывода и стандартной ошибки. Блокировка должна быть быстрой, поэтому перенаправление в заблокированный файл вряд ли подойдет. Блокировка нужна, чтобы избежать смешивание содержимого буферов двух и более конкурирующих процессов. >ну а то что вы привели это лишь один из IPC, надо >заметить самый простой, попробуйте на питоне сделать работу с разделяемой памятью >и блокировкой. >к примеру для алгоритма один писатель множестов читателей. >ваши друзья питонисты скажут вам спасибо. задача уже сто-один раз реализованна на практике. Популярности это не принесет, т.к. мало кто воспринимает эту проблему как краеугольный камень своей системы. Более того, быстродейственность системы зачастую только уменьшается при частом выделении и уничтожении объектов разделяемой памяти из-за перестройки индекса сегментов. Может быть "один писатель" и "множество читателей" реализуется более просто - разделяемая память не единственный метод. Почему вы пошли именно этим путем? Или это только пример?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	32. "Perl или Python кого изучать?"
	Сообщение от NuINu (??) on 16-Дек-08, 14:01
	> >>хорошо, но я на самом деле решал немного другую задачу(вне зависимости от >>заданного вопроса) как перенаправить любой вывод, даже самый неожиданный. >>для чего? в контексте разработки CGI приложений. когда ты используешь кучу сторонних >>библиотек. и любая из них, в случае ошибки, может выдать с >>stdout очень неприятную запись, что очень нехорошо с точки зрения безопасности. > >Именно для данной задачи лучше не перенаправлять стандартные выводы, а считывать через >popen функции: если есть вывод - открывать лог-файл, блокировать его эксклюзивной пробема в том что вы можете в своем проекте использовать кучу сторонних библиотек, и врядли каждый вызов в своей программе вы будете реализовывать через сторонний процесс. а в силу этого и нужно переопределение стдаута в основном процессе. >того, быстродейственность системы зачастую только уменьшается при частом выделении и уничтожении >объектов разделяемой памяти из-за перестройки индекса сегментов. > >Может быть "один писатель" и "множество читателей" реализуется более просто - разделяемая >память не единственный метод. Почему вы пошли именно этим путем? Или >это только пример? конечно это просто пример. на самом деле разделяемая память это оптимальный вариант обмена, лучше не бывает! можно конечно еще через пайпы и сокеты, но это гораздо медленне. если использовать триды то эквивалентно по скорости. но в данном случае я предлагал реализовывать взаимодействие между процессами. никакие индексы нигде при работе с разделяемой памятью не перестраиваются, мне кажеться вы  это с чем то путаете.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	33. "Perl или Python кого изучать?"
	Сообщение от BigHo on 16-Дек-08, 16:08
	>>Именно для данной задачи лучше не перенаправлять стандартные выводы, а считывать через >>popen функции: если есть вывод - открывать лог-файл, блокировать его эксклюзивной > >пробема в том что вы можете в своем проекте использовать кучу сторонних >библиотек, и врядли каждый вызов в своей программе вы будете реализовывать >через сторонний процесс. >а в силу этого и нужно переопределение стдаута в основном процессе. Никак не могу осознать необходимость такой схемы. Если библиотека не удовлетворяет по параметрам - наверняка ей можно найти замену. Если нужно именно эту, или альтернатива еще хуже - можно набросать серверный вариант или схему с запуском отдельного процесса. Если же все библиотеки внезапно начнут черте-что выводить в стандартный вывод, то как раз для этого случая я и держу под рукой баночку с цианидом. >конечно это просто пример. на самом деле разделяемая память это оптимальный вариант >обмена, лучше не бывает! можно конечно еще через пайпы и сокеты, >но это гораздо медленне. тесты вам бы доказали, что не намного медленней. Выигрыш не будет заметен для буферов малой протяженности: 1-2% - это не то, ради чего стоит жертвовать стабильностью программ. Конечно, есть еще интересное решение virtual ring buffer (в тему уменьшения количества операций копирования в режиме пользователя), но это уже о разделяемой памяти для одного процесса. >если использовать триды то эквивалентно по скорости. но в данном случае я >предлагал реализовывать взаимодействие между процессами. Да. Прошу все же заметить, что разделение памяти несколько отличается стабильностью в худшую сторону по сравнению с другими IPC методами. Обычно разделение на процессы делают тогда, когда хотят большей защищенности адресного пространства. pthread_mutex_* не смогут защитить, если один из процессов выйдет, забыв разлочить ранее заблокированный замок. В этом случае нет разницы: что используешь многопоточность, что разделяемую память - грабли, по конфигурации набитой шишки похожи, как близнецы. >никакие индексы нигде при работе с разделяемой памятью не перестраиваются, мне кажеться >вы  это с чем то путаете. Нет. Не путаю. Операции mmap/unmap могут сильно замедлить работу программы, если их использовать черезчур часто. Да на сегментацию процесса может сказаться не в лучшую сторону. Но не буду настаивать, возможно это особенности архитектуры только моей платформы.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	34. "Perl или Python кого изучать?"
	Сообщение от NuINu (??) on 16-Дек-08, 16:55
	>Никак не могу осознать необходимость такой схемы. Если библиотека не удовлетворяет по >параметрам - наверняка ей можно найти замену. Если нужно именно эту, >или альтернатива еще хуже - можно набросать серверный вариант или схему >с запуском отдельного процесса. Если же все библиотеки внезапно начнут черте-что >выводить в стандартный вывод, то как раз для этого случая я >и держу под рукой баночку с цианидом. > ооо!!! ужас! как вы только живы? или страдают только сторонние разработчики? :) >Нет. Не путаю. Операции mmap/unmap могут сильно замедлить работу программы, если их >использовать черезчур часто. Да на сегментацию процесса может сказаться не в >лучшую сторону. Но не буду настаивать, возможно это особенности архитектуры только >моей платформы. да да путаете, я про mmap ничего не говорил это своершенно другая область. эта вещь не предназначена для межпроцессного взаимодействия(вернее не предназначена только для него) хотя как я понимаю используется именно для него. ну не суть. я говорил про функции shmget/shmat/shmdt при этом при самой передаче данных ни одна из них не вызывается. т.е процесс происходит без участия ядра(кончено вызываются функции блокировки)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	38. "Perl или Python кого изучать?"
	Сообщение от BigHo on 16-Дек-08, 18:12
	>ооо!!! ужас! как вы только живы? или страдают только сторонние разработчики? :) Я бы сказал иначе: не страдают, а избавляются от страданий. Заодно и других перестают мучать. >да да путаете, я про mmap ничего не говорил это своершенно другая >область. эта вещь не предназначена для межпроцессного взаимодействия(вернее не предназначена только >для него) хотя как я понимаю используется именно для него. ну >не суть. > >я говорил про функции shmget/shmat/shmdt при этом при самой передаче данных ни >одна из них не вызывается. т.е процесс происходит без участия ядра(кончено >вызываются функции блокировки) Функции mmap семейства и shm* семейства не одинаковы, суть же их одна. Поэтому то, что было сказано для mmap - характерно и для shm*. Проще всего их рассматривать как интерфейс к ядру ОС по распределению оперативной памяти. Обращение за памятью через mmap и через shmat вызывает схожие процессы в ядре, и уж совершенно точно - используют одну и ту же архитектуру работы с виртуальными страницами. Речь идет не только про AMD64 eXecute и Read/Write биты, но и про указатели на листы памяти, которые хранятся совместно с этими битами. При выделении новой области нередко происходит сброс кеша процессора по этим таблицам. Если процесс "набрал" много памяти, то это требует большего процессорного времени по исполнению запроса на каждый новый участок памяти. В OpenSolaris, например, если процесс однажды откушал большой кусок памяти, то обратно она уже не возвращается, это как раз для того, чтобы перестройка таблиц не происходился слишком уж часто. Поскольку ссылок не предоставляю, вполне понятно почему можете мне не верить. Но увы: где, когда и на каком языке был источник(и) - уже не вспомню.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

35. "Perl или Python кого изучать?"

Сообщение от rasmon on 16-Дек-08, 16:58

Я не защищаю ни одну из представленных точек зрения. Но знаю мнение классика ))) Раймонд в "искусстве программирования для юникс" (он там не ругает какой-либо язык заметим), постоянно подчеркивает свою рекомендацию изучать пайтон и руби. И хотя там же говорит про превосходство с, с++ и жава, но считает, что в руби и пайтоне учтены все промахи других языков. Вот так

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	36. "Perl или Python кого изучать?"
	Сообщение от angra (ok) on 16-Дек-08, 17:31
	А, скажем, Ларри Уолл говорил другое. Устроим писькомерку "классиков"? Или может пора уже научится думать самостоятельно, а не дрочить на кумиров?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	39. "Perl или Python кого изучать?"
	Сообщение от rasmon on 16-Дек-08, 18:27
	>А, скажем, Ларри Уолл говорил другое. Устроим писькомерку "классиков"? Или может пора >уже научится думать самостоятельно, а не дрочить на кумиров? Не знаю что считал Ларри Уолл. Но так как он создатель перла  не трудно предположить его мнение. Ты видел в моем ответе слова "письки" и "кумир"? Вы юноша в общественнолм месте. Что я такого оскорбительного написал, что вызвал ваш святой гнев?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	41. "Perl или Python кого изучать?"
	Сообщение от angra (ok) on 16-Дек-08, 18:56
	Старичок не успевает за ходом мысли юноши? И не знает бородатых анекдотов и древних идиом? Не стесняйтесь, спрашивайте, разложим по полочкам, ведь к старикам(и тем кто себя таковым считает) везде у нас почет. Пока отвечу на заданный вопрос >Что я такого оскорбительного написал, что вызвал ваш святой гнев? Ничего оскорбительного, вы сморозили глупость характерную для подростков. Глупость не может быть оскорбительной, она может вызвать сочувствие, презрение, отвращение, усмешку и только в редких случаях гнев. На дураков знаете ли не принято гневаться.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	42. "Perl или Python кого изучать?"
	Сообщение от rasmon on 16-Дек-08, 19:33
	>Старичок не успевает за ходом мысли юноши? И не знает бородатых анекдотов >и древних идиом? Не стесняйтесь, спрашивайте, разложим по полочкам, пока ты тут только хамил. ничего не раскладывал >редких случаях гнев. На дураков знаете ли не принято гневаться. даже если я написал глупость - я никого не оскорблял. это слова про писькомер ты отнес к "древним идиомам"? и почему это ты считаешь себя вправе хамить на мнение с которым ты не согласен? а о том кто является дураком у модератора спроси. человек задал чисто риторический вопрос. Я посчитал за нужным высказать некое мнение. Мое отношение в данном вопросе неоднозначное кстати. Было интересно послушать что скажут.Для того и форум. А изголяться в "идиомах" в другое место иди
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	37. "Уууу... контафактный ESR, ахтунг"
	Сообщение от Andrey Mitrofanov on 16-Дек-08, 17:51
	>Раймонд в "искусстве программирования для юникс" >рекомендацию изучать пайтон и руби >говорит про превосходство с, с++ и жава >учтены все все промахи других языков. Ужас! Неужели я читал контрафактный паааддельный пииииратский TAOUP!??? Ж-O :-P Твой с голограмой был? >:-D
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	40. "Perl или Python кого изучать?"
	Сообщение от vic (??) on 16-Дек-08, 18:28
	>Я не защищаю ни одну из представленных точек зрения. Но знаю мнение >классика ))) >Раймонд в "искусстве программирования для юникс" (он там не ругает какой-либо язык >заметим), постоянно подчеркивает свою рекомендацию изучать пайтон и руби. И хотя >там же говорит про превосходство с, с++ и жава, но считает, >что в руби и пайтоне учтены все промахи других языков. Вот >так Недостаточное понимание смысла тех или иных фич иногда приводит к восприятию их как недостатков и промахов. язык - инструмент, универсального нет. многое зависит от задачи.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]