Transact SQL великолепный язык, функциональности которого более чем достаточно для решения большинства часто возникающих задач. Однако иногда возникают задачи, которые с его помощью решать долго и/или неудобно. Пожалуй, самым ярким примером является продвинутый парсинг строк, в котором приходится использовать регулярные выражения или просто хитрый и закрученный алгоритм. Начиная с SQL Server 2005, эта проблема решается созданием хранимой процедуры/функции CLR. Но этот подход требует перекомпиляции и развертывания сборки при внесении изменений. А так хочется, не покидая Management Studio, изменять поведение своих процедур.
Естественным образом возникает желание встроить в T-SQL поддержку какого-нибудь скриптового языка, чтобы выполнять код на лету. Благодаря DLR (Dynamic Language Runtime) в .Net Framework 4 у нас появилась такая возможность. Исключительно в силу личных пристрастий автора в качестве такого языка был выбран IronPython.
Под катом пошаговая инструкция и демонстрация результата.
Читать полностью »
Метка «ironpython»
Используем IronPython из Transact SQL
2013-01-03 в 12:12, admin, рубрики: .net, DLR, ironpython, python, sql server, метки: c++, DLR, ironpython, sql serverВзаимодействие интерпретаторов Python-IronPython-Jython
2012-09-21 в 7:40, admin, рубрики: .net, ironpython, java, jython, python, межпроцессное взаимодействие, метки: .net, ironpython, java, jython, python, межпроцессное взаимодействие Возникла необходимость в решении такой задачи: как обмениваться данными между разными интерпретаторами Python?! Отыскал несколько решений, но хочу рассказать об одном, на мой взгляд, самом удобном.
Читать полностью »
Делаем standalone exe на IronPython
2012-08-15 в 8:50, admin, рубрики: .net, exe, ironpython, python, windows, метки: .net, exe, ironpython, python, windows Иногда требуется написать маленькую программу, которая будет распространяться в виде исполняемого файла, и при этом не хочется, чтобы с программой ещё было море файлов. Один exe-шник и всё, да при этом хочется, чтобы его написание не занимало много времени (какой-нибудь лёгкий язык).
CPython в комплекте с py2exe или cx_Freeze не даёт требуемого результата: много файлов и большой размер программы, хотя и работает очень быстро.
Даже попробовал в Racket Creating Stand-Alone Executables, но хотелось всё же использовать Python, так как много наработок. Да и Racket тоже сгенерировал немало дополнительного «мусора».
Чистое решение смог получить в IronPython с помощью встроенного компилятора pyc. Даже IDE не потребовалась. Подробности под катом.
Читать полностью »
Python vs. IronPython: вычисление MD5-хеша
2012-08-15 в 4:44, admin, рубрики: .net, ironpython, md5, python, Песочница, производительность, метки: ironpython, MD5, python, производительностьПонадобилось как-то в проекте сделать автообновление для клиентского приложения. Так как работало оно с отечественными криптопровайдерами, доступ к которым проще получить из .Net, написано оно было на IronPython. При этом C# выбран не был, так как на стороне сервера уже активно использовался python и сильно переучиваться не хотелось.
Казалось бы всё просто. Был набросан скрипт, который вычисляет md5-хеши для файлов входящих в состав приложения, сводит всё в один файл со строками вида “относительный путь”:”md5” и выкладывает в директорию раздачи статики nginx. Клиентское приложение при запуске забирает файлик, прогоняет аналогичный скрипт, и сверяет полученный результат с эталоном.
Но тут обнаружилась маленькая деталь. В IronPython скрипт выполнялся в несколько раз медленнее. И это на достаточно быстром железе. У пользователя же оно могло быть значительно слабее. Началась оптимизация, в ходе которой родилась мысль провести сравнение производительности Python и IronPython на этом примере. В статье, соответственно, рассматриваются три отдельных результата: для Python, IronPython и IronPython с адаптированным скриптом.
Результаты под катом.
Читать полностью »
CPython vs. IronPython: вычисление MD5-хеша
2012-08-15 в 4:44, admin, рубрики: .net, ironpython, md5, python, производительность, метки: ironpython, MD5, python, производительностьПонадобилось как-то в проекте сделать автообновление для клиентского приложения. Так как работало оно с отечественными криптопровайдерами, доступ к которым проще получить из .Net, написано оно было на IronPython. При этом C# выбран не был, так как на стороне сервера уже активно использовался python и сильно переучиваться не хотелось.
Казалось бы всё просто. Был набросан скрипт, который вычисляет md5-хеши для файлов входящих в состав приложения, сводит всё в один файл со строками вида “относительный путь”:”md5” и выкладывает в директорию раздачи статики nginx. Клиентское приложение при запуске забирает файлик, прогоняет аналогичный скрипт, и сверяет полученный результат с эталоном.
Но тут обнаружилась маленькая деталь. В IronPython скрипт выполнялся в несколько раз медленнее. И это на достаточно быстром железе. У пользователя же оно могло быть значительно слабее. Началась оптимизация, в ходе которой родилась мысль провести сравнение производительности CPython и IronPython на этом примере. В статье, соответственно, рассматриваются три отдельных результата: для CPython, IronPython и IronPython с адаптированным скриптом.
Результаты под катом.
Читать полностью »
Кросс-вмный (CLR/JVM) код на Python
2012-07-25 в 14:13, admin, рубрики: .net, clr, ironpython, java, jython, python, кроссплатформенная разработка, метки: clr, ironpython, java, jython, python, кроссплатформенная разработкаЭто узкоспециализированная короткая заметка про то, как я запинывал write once, run everywhere тесты для библиотеки, портированной с C# на Java, при помощи Python.
Смысл в следующем: есть большая, толстая и красивая библиотека, которая была по коммерческим соображениям портирована с C# на Java. API осталось почти одинаковым, naming conventions естественно сменились при переходе на другой язык. Нам нужно было написать толстую пачку тестов, проверяющих, что клон библиотеки работает идентично оригиналу (тесты на регрессии, иными словами). Для этого сравнивались результаты работы кода библиотек (некие бинарники и xml-метаданные). Тесты были нетривиальные, их было много, и что самое неприятное — они постоянно дописывались с одного конца командой из четырех человек. Некоторое время я старательно портировал их на Java, затем плюнул и предложил команде писать тесты на языке, который сразу можно было бы выполнять на CLR (со старой библиотекой) и на JVM (с клоном). Оказалось, они и сами уже некоторое время думали про Python, Читать полностью »