Насчет этого примера с -0xFFFFFFFF - по моему, тут все понятно. Если писать без скобок, то это воспринимается как одна константа. Абсолютное ее значение занимает 32 бита + 1 бит на знак - не укладываемся в int - делаем long (Питоновский long это как BigInt в Перле - целое произвольной длины). Если же писать -(0xFFFFFFFF), то получится что делается 32-битный int, в котором все биты =1. То есть -1. Берем от него минус и получаем 1. Подобных неоднозначностей в любом развивающемся языке избежать нельзя, а в команде Питон уже договорились, как будут решать эту проблему. В 2.3 будет 1 в обоих случаях, а во всех следующих версиях, когда тип int и long уже будут эквивалентны -4294967295.

2Sun-ch. Ну в общем кода меньше, а в скорости выигрыш не намного больше, да и проц. жрет как свинья.

>Korwin А в чем изврат ты мне объясни ТЫ имеешь 150 МгБ данных тебе надо
>их отсортировать Наверное что бы быстрее искать ? Я не ошибаюсь ? там
>есть PK (ведь есть же А?) Ну и чем это не база?

А почитать тред не удосужился? Анонимус. Речь о том, что подготавливался русский словарь для OO. Т.к. у него несколько отличный формат от aspell и ispell приходилось не только конвертировать rules, но также и все остальное.

Немного не в тему, но все же:
>3) В Python реализована динамическая типизация, и кто-ты такой чтобы
>решать что есть гуд, а что не гуд? Ты разрабатывал когда-нибудь языки?

Ну я разрабатывал. И должен сказать что динамическая типизация хороша для скриптовых языков, для языков реального времени, а также там где важна _надежность_ динамическая типизация ЗАПРЕЩЕНА. Если есть возражения, то удосужтесь почитать С.Янг, V. Ullman, Wirth N. ну или Дейкстру.

Diomidis Spinellis. Code Reading: The Open Source Perspective.

2Korwin

Ну че ! Съел ? Решение в вызове 1 функции :)

CPAN рулит однозначно !

Подобных неоднозначностей в любом развивающемся языке избежать нельзя, а в команде Питон уже договорились, как будут решать эту проблему. В 2.3 будет 1 в обоих случаях, а во всех следующих версиях, когда тип int и long уже будут эквивалентны -4294967295.

Т.е. существующая программа работающая интенсивно с вычислениями может "вдруг" на новой версии давать отличные от первоначальных результаты? Ужас.

2Sun-ch. Ты мои ответы читаешь?

А теперь сравни выполнение твоего кода и "sort | uniq"... Perl хорош для работы со средними размерами данных при условии, что работа ведется в одной кодировке. Пока так. А дальше. Другие языки на месте не стоят :)

Diomidis Spinellis. Code Reading: The Open Source Perspective.

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

Хочешь быстро ? Используй Berkeley DB (SleepyCat). На огромных файлах

гигабайты)

быстрее ничего работать не будет.

Diomidis Spinellis. Code Reading: The Open Source Perspective.

А sort умеет сортировать сложные структуры ?

сat my_file

1111111111111111111ъъъъъъГГГГГГГГГГГГГГ 1111111нннн1111111ъъъъъъГГГГГГГГГГГГГГ 1111111111111шшшш1111ъъъъъъГГГГГГГГГГГГГГ 1111яяяяяяяяяяяяяяяяяяяяяяяяя11111111111ъъъъъъГГГГГГГГГГГГГГ

Это таблица из 2 столбцов в качестве разделителя пятый 'ъ'

Отсортируй строки по 1 столбцу.

> Хочешь быстро ? Используй Berkeley DB (SleepyCat). На огромных файлах

Значит или перл или BDB ? А шелл значит низзя? Просто удивительно до чего доходят некоторые индивидумы в своем нежелании признавать очевидное!

Даже чтобы использовать твой вариант с BDB придется сперва залить туда данные, и потом слить. Это напоминает пример с передачей информации в контейнерах с CD: скорость умопомрачительная, но только если не учитывать время на запись/чтение ;)

Diomidis Spinellis. Code Reading: The Open Source Perspective.

Значит или перл или BDB ?

Ну я же сказал на больших файлах, например все логи squid за год

>>Есть волшебный оператор tie, который свзывает хеш с чем угодно хоть с базой на Oracle размером в 100 Террабай
>Это намек на то, что мне надо было все записи (несколько сотен тысяч) загнать в БД и с ними работать через tie??? Ни и изврат я скажу :)
Это не намек, Корвин, здесь практически прямым текстом сказано откуда у тебя растут руки

какие еще логи squid? вроде задачка была вполне конкретная -- остортировать 150 метров слов русского языка по одному слову с строке. и команда sort | uniq здесь оптимальное решение. даже если не учитывать время на чтение документации и написание собственно скрипта

112!

112! И выходим в Top10!!! :-)

Ну и нафлеймили вы...

Diomidis Spinellis. Code Reading: The Open Source Perspective.

остортировать 150 метров

А если 150 километров, которые не влезут в один файл ?

2Sun-ch. "Какой заяц, какое море!" (с) грузинского мультика :)
Проглотил?
А по поводу сортировки второго столбца. man sort - можно сортировать не только с первых символов, а если надо более сложную структуру, то в цепочку добавь awk.

В прочем у меня так и работало. awk выдерало из сложной структуры необходимые вещи, sort сортировал, а uniq удалял дубляжи.

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

Вот вам и обработка текста.

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

2Sun-ch. Не надоело?

вот только не надо прикидываться дурачком!

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

задача -- __конкретная__. Я не обсуждаю обощенные случаи, а пытаюсь обратить внимание на то как ставился вопрос.

2Korwin:
>Т.е. существующая программа работающая интенсивно с вычислениями >может "вдруг" на новой версии давать отличные от первоначальных >результаты? Ужас.

1. Этот эффект проявляется _только_на_шестнадцатеричных_константах_,
в любых выражениях
результат не меняется от наличия или отсутствия лишних скобок.
Например, -(0xFFFFFFFE+1) = 1 в любой версии Питон.
Скажу это по-другому. Этот эффект не может возникнуть "вдруг"
во время выполнения программы и не зависит от входных данных.
Все, что нужно, это посмотреть (с помощью какого-нибудь скрипта)
исходный текст на предмет наличия -0x... и выдать в этом месте
предупреждение. Не сомневаюсь, что это появится или в pychecker,
или в самом Python.
Люди ведь не перестают пользоваться C, из-за того
что действие выражений типа foo(i++, i++) не определено, или
из-за того что можно внутри if можно случайно написать = вместо ==.

2. Программы с интенсивыми вычислениями как правило:
a) используют floating-point
b) используют численные модули, такие как Numeric
с) используют расширения на C/C++.

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

Например: какой метод сортировки вы предпочитаете:
1 Пузырьком
2 Делением пополам
3 Утруской в мешке (только для задачи сортировки гороха)
4 Загнать все в BDB (а лучше Oracle) прикрутить tie и \@!

Флеймим дальше ;;)

anonymous (*) (2003-07-10 21:01:39.39564) c http://www.softpanorama.org/index.shtml рулит адназнача!
Пункт 8 The two-level approach ("scripting language" + "compiled language" like TCL + C or "Python + C") to the design of software as alternative to the fashionable "a single OO language" по-моему есть окончательное решение всех этих флеймов какой язык лучше, и бессмысленных поисков серебрянных пуль.
Более того - он делает бессмысленным все технологии на основе COM, CORBA и тд. Нафиг оно все нужно, если через пайп можно передать любые скриптовые команды, выполняемые на server-application.
Более того - killer monster applications (a'la OpenOffice) вааще должны сдохнуть как динозавры. Профессиональные программеры должны заняться тем для чего их в начале и придумали - для разработки специализированных языков (библиотек). А юзеры (или программеры-любители)- заняться написанием скриптов на основе этих языков для решения своих конкретных задач.
Я не большой поклонник питона, но тоже присоединяюсь "GvR - великий человек, спасибо ему, желаю ему удачи на новом месте."

Diomidis Spinellis. Code Reading: The Open Source Perspective.

>а если надо более сложную структуру, то в цепочку добавь awk.

Еще забыли про sed

Perl это sed+awk+sort+sh в одном флаконе.

Это и было одной из целей создания языка

это язык-клей для ленивых программистов :)

однако Sun-ch определенно не ленив, во всяком случае в пропаганде перла. ж)

Diomidis Spinellis. Code Reading: The Open Source Perspective.

однако Sun-ch определенно не ленив, во всяком случае в пропаганде перла. ж)

Просто сильно веселят такие заявления:

>Язык был спроектирован для написания однострочных скриптов, и этим все сказано.

>удел перла - скрипты BSD и прочие устаревшие и унаследованные приложения.

Че угодно, лишь бы BSD пнуть :)

Как это не удивительно, но все rc* скрипты в *BSD написаны на sh

>LISP -- та еще скобочная порнография

Говорят смех укрепляет иммунитет ?

> Более того - он делает бессмысленным все технологии на основе COM,
> CORBA и тд. Нафиг оно все нужно, если через пайп можно передать любые
> скриптовые команды, выполняемые на server-application.

Что-то я не вкурил, как это? Почему вдруг CORBA нафиг?

> Говорят смех укрепляет иммунитет ?

нет. говорят смех продляет жизнь. меня например забавит вот это:

----------------------- какие еще логи squid? вроде задачка была вполне конкретная -- остортировать 150 метров слов русского языка по одному слову с строке. и команда sort | uniq здесь оптимальное решение. даже если не учитывать время на чтение документации и написание собственно скрипта

anonymous (*) (2003-07-11 14:22:30.35832) ----------------------- остортировать 150 метров

А если 150 километров, которые не влезут в один файл ?

Sun-ch (*) (2003-07-11 14:33:42.75333) -----------------------

> Как это не удивительно, но все rc* скрипты в *BSD написаны на sh

не удивительно. так как только что было продемонстрировано что sh бывает проще и быстрее чем perl

Diomidis Spinellis. Code Reading: The Open Source Perspective.

так как только что было продемонстрировано что sh бывает проще и быстрее чем perl

Для очень узкого круга очень простых задач.

На perl написан полноценный shell

На sh напишем perl ?

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

-----------------------
какие еще логи squid? вроде задачка была вполне конкретная --
остортировать 150 метров слов русского языка по одному слову с строке.
и команда sort | uniq здесь оптимальное решение. даже если не учитывать
время на чтение документации и написание собственно скрипта

anonymous (*) (2003-07-11 14:22:30.35832)
-----------------------
остортировать 150 метров

А если 150 километров, которые не влезут в один файл ?

Sun-ch (*) (2003-07-11 14:33:42.75333)
-----------------------

> Для очень узкого круга очень простых задач.

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

А зачем?
Что выполучите от использования COBRA? У вас есть server-application с embedded скриптовым языком и доступ к необходимой функциональности через этот язык обеспечен. Таким образом любой вызов процедуры внутри сервера можно проделать подавая на вход набор скриптовых команд, а для этого простого пайпа больше чем достаточно.
Идея как бы в том, что экспорт функция с 1 уровня (компилируемый язык) на втрой (скриптовой) дает ту же самую функциональность, что и экспорт на COM/CORBA интерфейс.
Если я не прав - поправьте.

2all.

Эх. Молодеж. А сути так и не поняли.

>>так как только что было продемонстрировано что sh бывает проще и
>>быстрее чем perl
>Для очень узкого круга очень простых задач.
>На perl написан полноценный shell
>На sh напишем perl ?
Как писал раньше. Для _каждой_ задачи есть свой оптимальный подход/язык. Поэтому чем больше языков знаете и применяете тем эффективней решаете поставленные перед вами задачи.

По поводу rc* скриптов на sh. Sun-ch, ведь в этих скриптах и не должно быть много сложной логики. sh справляется на ура и гораздо быстрее чем Perl. Плюс с ними работать приятнее чем с Perl кодом. Плюс переносимость выше (см. объем и требования sh и Perl интерпретаторов).

2geekkoo. Ты в корне не прав на счет замены функциональности CORBA скриптованием. Это, скорее всего, от незнания client-server технологий и в, частности, вопросов безопасности.

Да, да. Именно безопасности. Первая и явная проблема "вас есть server-application с embedded скриптовым языком" в плане безопасности. Если клиент может выполнять _произвольный_ код на стороне сервера, то...

Как вариант смены CORBA на что-то более легкое, и одновременно похожее на UNIX-way может быть SOAP протокол от Microsoft... Как не странно. Мда :)
Фишка в том, что SOAP гоняет XML запросы по HTTP (и не только) протоколу. Позволяя вызывать функции и методы независимо от того на каких языках написанны клиент и сервер. К тому же существуют способы авторизации, делегирования прав на выполнение тех или иных методов, шифрование/компрессия сообщений для безопасности и скорости.
SOAP протокол можно гонять через пайпы, вот и получим UNIX-way. Только в отличии от CORBA скорость будет ниже из-за использования XML вместа бинарного формата.

> Идея как бы в том, что экспорт функция с 1 уровня (компилируемый язык) > на втрой (скриптовой) дает ту же самую функциональность, что и экспорт > на COM/CORBA интерфейс.

Ага. Но со стороны программы на C это как бы то же самое -- нужно предоставить какой-то способ вызова своих подпрограмм и передачи данных.

Что касается COM, то там уже можно использовать в качестве связки между C-приложениями python/vb/jscript, с CORBA я такого еще не делал, но не думаю что принципиальные сложности есть.

Однако мне казалось что CORBA (и, забыл как его, распределенный COM -- COM+ ?) предоставляют некие сервисы, выходящие за рамки pipes, и тогда функциональность не эквивалентна.

В таком виде оно как раз без проблем работает.
А проблема в том что если L не ставить, то получается,
что тип присваивается integer,
этого типа границы от -2147483648 до 2147483647
в случае если вы задаете числовой литерал в десатичном виде,
то при выходе за границы типа преременная автоматически преобразуется
к типу long int, для шестнадцатиричных литералов этого не делается,
а для величин больших чем 2147483647 прозводится вычитание
4294967296 после чего рего результат становится отрицательным.
Это и описано в в доках пример:
>>>a=0xffffffff# т.е 4294967295-4294967296=-1
>>>a
-1
>>>b=-(0xffffff) # очевидно -(-1)=1
>>> b
1

А вот a=-0xffffffff корректно преобразуется к типу long int

129!Ё

догоним и перегоним wxWindows-2.4.1!

Diomidis Spinellis. Code Reading: The Open Source Perspective.

Эх. Молодеж. А сути так и не поняли.

Это Вы к сож. сути не поняли, почитайте введение в Lama Book,

там философия perl изложена достаточно внятно.

>По поводу rc* скриптов на sh. Sun-ch, ведь в этих скриптах и не должно быть много сложной логики. sh справляется на ура и гораздо быстрее чем Perl. Плюс с ними работать приятнее чем с Perl кодом. Плюс переносимость выше (см. объем и требования sh и Perl интерпретаторов).

Это не всегда так. Иногда остановка демона весьма не простая задача.

Убейте smbd процессы и быстро в этом убедитесь.

Да и отлаживать sh скрипты сложнее.

Читал эту книгу. Вам бы посоветовал читать не только про Perl. Расширяйте кругозор пока молодой! Потом будет тяжко :)

>1) В Python нет указателей, есть только ссылки. Я отношу это к >достоинствам языка.

2) В синтаксисе ты наврал __this__ это непонятно что, вот this понятно, и self понятно, а __this__?

Согласен. Имелось ввиду self :)

>3) В Python реализована динамическая типизация, и кто-ты такой чтобы >решать что есть гуд, а что не гуд? Ты разрабатывал когда-нибудь >языки?

А я и не решаю. Мне лично кажется это неудобным. А местами и неоднозначным. Если я спроектипровал класс, а потом в __init__(self)
начал порождать переменные класса, которые не были заложены в дизайн
изначально? Поричем не по злому умыслу или по незнанию, а из-за опечатки?

А наезды типа "кто ты такой?" считаю неконструктивными :( и неотносящимися к теме разговора.

>Объекты перла, это объекты перла, и в принципе ничем не уступают >классам Python, просто непривычные немного.

Почему? Классы питона вполне привычны человеку, писавшему на том же С++ или Eiffel. Вот передавать self -- действительно непривычно. И накладывает определенную дисциплину.

>Всё что я перечислил это просто совйства языков, зная их можно >принять решение использовать эти языки в проекте или нет. Ниша для >Python огромна, а примеры использования можно посмотреть здесь:
>http://pythonology.org/success

Есть подозрение, что ниша для любого алгоритмически полного языка огромна. Весь вопрос в удобстве и наличии "носителей" языка :)

--------------------------------

>Зайди в любой офис и спроси любую секретаршу что такое >дизассемблирование. Как ты думаешь, что она тебе скажет?

ГЫ Зашел к бухшам и сказал

Так дефки, ща буду вас дизассемблировать.

Саныч, да мы по 2 раза замужем уже побывали, покраснев ответили

дефки :)

Sun-ch (*) (2003-07-11 14:48:34.252846)

Этак смачно прокатив букву СССС :)))))

-------------------------------- LOL

;)))))

2Sun-ch:

>Просто сильно веселят такие заявления: >>Язык был спроектирован для написания однострочных скриптов, и этим все сказано.

Про остальные высказывания говорить не буду, поскольку они не мои, а вот по поводу Perl'а попробую обосновать свое высказывание. В Perl есть несколько моментов, которые заставляют меня считать его языком спроектированным для очень коротких программ (которые я аллегорически назвал однострочными): 1. Есть опция коммандной строки (-e кажется) которая позволяет выполнить перловое выражение. По-моему, эта фича существует с самых первых версий. Поиск в Google "perl oneliners" дает представление, что с этим можно вытворять. 2. _Куча_ неявных переменных во главе $_ - чтобы не надо было объявлять переменные и как-то их передавать по функциям. Видимо, чтобы устранить всякие нехорошие эффекты от использования таких переменных, ввели local переменные с динамической областью видимости (не путать с my переменными со статической областью видимости!) 3. Отсутствие прототипов ф-ций (!) (какая-то пародия на прототипы появилась в Perl 5) - тоже видимо для краткости и совместимости с sh. 4. Монолитный бинарник perl который включает в себя 90-99% всего необходимого для текстовой обработки (в понимании Perl'а) + еще чуть-чуть. Видимо, чтобы сэкономить на "use ..." 5. Несколько экзотических операторов типа (синтаксис не помню) "взять только N верхних строк и M нижних строк файла f" 6. Гипертрофически развитые регулярные выражения. С помощью них можно даже раскладывать числа на сомножители и решать Диофантовы уравнения. Но (!) в то же время: 6.1. В то же время для разбора простой контексно-свободной грамматики нужно долго рыться в CPAN'e. 6.2. Регулярные выражения (как и файлы кстати) это не first-class объекты. Их нельзя сформировать на лету, передать в функцию и т.д. Нет, есть, конечно, всемогущий eval, но это достаточно кривое решение. 7. Любую программу на Perl можно записать в одну строку :) Я признаю, что Perl5 сделал несколько шагов в направлении больших программ. Появились ссылки (которым в стандартной Перловой документации посвящено целое руководство (+ нескольких tutorials в Инете), видимо из-за их "очевидности". Появилось OOP (правда нервным и любителям Smalltalk на то реализацию конструкторов и наследования лучше не смотреть, хотя использование уже кем-то написанных классов довольно прозрачно). Да, на Перл сделаны несколько относительно крупных вещей, как то autoconf & automake, но, как кто-то здесь уже заметил, шедевр можно написать и на Basic. Хотя я autoconf и automake к шедеврам не отношу, но нахожу их полезными на данном этапе.

2Sun-ch:

>Просто сильно веселят такие заявления:
>>Язык был спроектирован для написания однострочных скриптов, и этим все сказано.

Про остальные высказывания говорить не буду, поскольку они не
мои, а вот по поводу Perl'а попробую обосновать свое высказывание.
В Perl есть несколько моментов, которые заставляют меня считать
его языком спроектированным для очень коротких программ (которые я
аллегорически назвал однострочными):
1. Есть опция коммандной строки (-e кажется) которая позволяет
выполнить перловое выражение. По-моему, эта фича существует с
самых первых версий. Поиск в Google "perl oneliners" дает
представление, что с этим можно вытворять.
2. _Куча_ неявных переменных во главе $_ - чтобы не надо было
объявлять переменные и как-то их передавать по функциям.
Видимо, чтобы устранить всякие нехорошие эффекты от
использования таких переменных, ввели
local переменные с динамической областью видимости
(не путать с my переменными со статической областью видимости!)
3. Отсутствие прототипов ф-ций (!) (какая-то пародия на прототипы
появилась в Perl 5) - тоже видимо для краткости и совместимости с
sh.
4. Монолитный бинарник perl который включает в себя 90-99% всего
необходимого для текстовой обработки (в понимании Perl'а)
+ еще чуть-чуть. Видимо, чтобы сэкономить на "use ..."
5. Несколько экзотических операторов типа (синтаксис не помню)
"взять только N верхних строк и M нижних строк файла f"
6. Гипертрофически развитые регулярные выражения. С помощью них
можно даже раскладывать числа на сомножители и решать Диофантовы
уравнения. Но (!) в то же время:
6.1. В то же время для разбора простой контексно-свободной
грамматики нужно долго рыться в CPAN'e.
6.2. Регулярные выражения (как и файлы кстати)
это не first-class объекты. Их нельзя сформировать на лету,
передать в функцию и т.д. Нет, есть, конечно, всемогущий eval,
но это достаточно кривое решение.
7. Любую программу на Perl можно записать в одну строку :)

Я признаю, что Perl5 сделал несколько шагов в направлении больших
программ. Появились ссылки (которым в стандартной Перловой
документации посвящено целое руководство (+ нескольких tutorials
в Инете), видимо из-за их "очевидности". Появилось OOP (правда нервным и любителям Smalltalk на то реализацию конструкторов и наследования лучше не смотреть, хотя использование уже кем-то написанных классов довольно прозрачно).
Да, на Перл сделаны несколько относительно крупных вещей, как то autoconf & automake, но, как кто-то здесь уже заметил, шедевр
можно написать и на Basic. Хотя я autoconf и automake к шедеврам
не отношу, но нахожу их полезными на данном этапе.

> Как вариант смены CORBA на что-то более легкое, и одновременно похожее > на UNIX-way может быть SOAP протокол от Microsoft... Как не странно. Мда :)

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

И SOAP все-таки стандартизуется W3C, а не MS.

Дерьмо ваш Perl. Python намного рулезнее...

Diomidis Spinellis. Code Reading: The Open Source Perspective.

>Да, на Перл сделаны несколько относительно крупных вещей,

http://perl.oreilly.com/news/success_stories.html

Это примеры "относительно" крупных вещей.

Diomidis Spinellis. Code Reading: The Open Source Perspective.

>Нет, есть, конечно, всемогущий eval, но это достаточно кривое решение.

Интересно, почему создатели lisp так не считают ?

Там eval очень популярен.

>шедевр можно написать и на Basic.

Этто дааа, один чувак года три назад написал x86 Assembler на Bash'e. Чиста из любви к извращениям. Раньше лежал здесь, но где теперь не знаю - кто хочет пусть сам ищет...

ftp://linux01.gwdg.de/pub/cLIeNUX/interim/shasm.TGZ

2 Sun-ch: ну-ка, решение задачи сортировки 150Мб слов, на перле, короче чем "sort<x|unique" ?

Слабо ?!

тьфу ...

unique/uniq

насчет -0xFFFFFFFF и -(0xFFFFFFFF)

- Through a bytecode optimizer bug (and I bet you didn't even know
  Python *had* a bytecode optimizer :-), "unsigned" hex/oct constants
  with a leading minus sign would come out with the wrong sign.
  ("Unsigned" hex/oct constants are those with a face value in the
  range sys.maxint+1 through sys.maxint*2+1, inclusive; these have
  always been interpreted as negative numbers through sign folding.)
  E.g. 0xffffffff is -1, and -(0xffffffff) is 1, but -0xffffffff would
  come out as -4294967295.  This was the case in Python 2.2 through
  2.2.2 and 2.3a1, and in Python 2.4 it will once again have that
  value, but according to PEP 237 it really needs to be 1 in Python
  2.2.3 and 2.3.  (SF #660455)

Sun-ch, как всегда, отвечает вопросом на вопрос, причем не на тот, какой ему задавался:
-------------------------
В Perl есть несколько моментов, которые заставляют меня считать его языком спроектированным для очень коротких программ (которые я аллегорически назвал однострочными):
...
6.2. Регулярные выражения (как и файлы кстати) это не first-class объекты. Их нельзя сформировать на лету, передать в функцию и т.д. Нет, есть, конечно, всемогущий eval, но это достаточно кривое решение.
...
anonymous (*) (2003-07-11 16:19:00.530518)
-------------------------
Интересно, почему создатели lisp так не считают ?
Там eval очень популярен.
Sun-ch (*) (2003-07-11 17:18:12.187537)
-------------------------
то есть он вроде и согласен, что в перле eval не популярен, но зато в лиспе используется, а значит перл крут -- правильно я понимаю?

Молодежь ;)))

Diomidis Spinellis. Code Reading: The Open Source Perspective.

2 Sun-ch: ну-ка, решение задачи сортировки 150Мб слов, на перле, короче чем "sort<x|unique" ?

Да нех делать :)

perl -e "print `sort<x|uniq`"

что, правда???? на питоне:

>>> len("sort<x|uniq")>len('''perl -e "print `sort<x|uniq`"''') 0

а на перле неужто 1? или слово "короче" можно пропустить как малозначимое?

>>Первая и явная проблема "вас есть server-application с embedded скриптовым языком" в плане безопасности. Если клиент может выполнять _произвольный_ код на стороне сервера, то...

Что значит произвольный??
Тока те команды, которые сервер захотел экспортировать в скрипт, а тут уж пусть у сервер-писателей голова болит какие команды безопасные, а какие нет
Korwin вы же в тикле рубите. Неужели некогда не встраивали его в С-приложение? Тут еще некоторые усилия нужно приложить, чтобы С-шная функция была в тикле видна.
А XML - это вааще очередной CS-buzzword. Попытка подменить нормальные языки непонятным поделием. Если уж делать стандарт, то на основе пристойного скриптового языка - tcl,guile, того же python (кто там еще претендовал на встраиваемость?)