Миграция от CPython до Jython
Я бы рекомендовал использовать PDO (объекты данных PHP) для запуска параметризованных SQL-запросов.
Это не только защищает от SQL-инъекции, но и ускоряет выполнение запросов.
И используя функции PDO, а не mysql_, mysqli_ и pgsql_, вы делаете свое приложение немного более абстрактным из базы данных, в редких случаях, когда вам нужно переключать поставщиков баз данных .
4 ответа
До сих пор я заметил две дальнейших проблемы:
- Строка, интернирующая не гарантируемый (и это - просто счастливая случайность реализации на CPython). Это могло быть серьезной проблемой, и действительно было в одной из библиотек, которые я портировал (Jinja2). Модульные тесты являются (как всегда) Вашими лучшими друзьями!
Jython 2.5b0 (trunk:5540, Oct 31 2008, 13:55:41)
>>> 'a' is 'a'
True
>>> s = 'a'
>>> 'a' is s
False
>>> 'a' == s
True
>>> intern('a') is intern(s)
True
Вот та же сессия на CPython:
Python 2.5.2 (r252:60911, Oct 5 2008, 19:24:49)
>>> 'a' is 'a'
True
>>> s = 'a'
>>> 'a' is s
True
>>> 'a' == s
True
>>> intern('a') is intern(s)
True
- os.spawn* функции не реализованы. Вместо этого используйте subprocess.call. Я был удивлен действительно, поскольку реализация с помощью subprocess.call будет легка, и я уверен, что они примут патчи.
(я делал подобную вещь как Вы, портировав приложение недавно)
Когда я некоторое время назад переключил проект с CPython на Jython, я понял, что для критичных по времени секций я понял, что скорость снижена до 50 раз. Из-за этого я остался с CPython.
Однако это могло измениться в текущих версиях.
Прежде всего, я должен сказать, что реализация Jython очень хороша. Большинство вещей «просто работает».
Вот несколько вещей, с которыми я столкнулся:
Модули C, конечно, недоступны.
open ('file'). Read () не закрывает файл автоматически. Это связано с разницей в сборщике мусора. Это может вызвать проблемы со слишком большим количеством открытых файлов. Лучше использовать идиому "with open ('file') as fp".
Установка текущего рабочего каталога (с помощью os.setcwd ()) работает для кода Python, но не для кода Java. Он эмулирует текущий рабочий каталог для всего, что связано с файлами, но может делать это только для Jython.
При синтаксическом анализе XML будет предпринята попытка проверить внешнее DTD, если оно доступно. Это может вызвать значительное замедление кода обработки XML, поскольку синтаксический анализатор будет загружать DTD по сети. Я сообщил об этой проблеме , но пока она остается нерешенной.
Метод __ del __ вызывается в коде Jython очень поздно, а не сразу после удаления последней ссылки на объект.
Существует старый список различий , но последний список недоступен.
Вы также можете изучить JPype . Я не уверен, насколько он зрел по сравнению с Jython, но он должен позволить CPython получать доступ к Java-коду.