Сравнение IronPython и Original Python. Что я могу ожидать от первого?
Я хочу изучать Python, но я весь день работаю в.Net в качестве разработчика на C#, поэтому я решил загрузить и установить IronPython и интегрированную студию IronPython. Насколько он отличается от оригинального Python? Как разработчик.Net могу ли я без проблем запускать обычный сценарий Python в среде.Net или это все та же старая утопия миграции? Чего мне ожидать?
Заранее спасибо.
РЕДАКТИРОВАТЬ: DIC. 2009 - IronPython был недавно обновлён до версии 2.6. Пожалуйста, обновите ваши ответы, если это возможно.
2 ответа
В вашей ситуации совершенно разумно изучать IronPython (тем более что эта книга отлично помогает вам в этом!). Вы получите доступ практически ко всем функциям Python 2.5 (не уверен, когда IronPython будет обновлен до версии Python 2.6, но 2.5 уже вполне пригоден для использования), а также ко всем библиотекам.Net и сборкам, которые вы знаете и любите, и таким инструментам как надстройки Visual Studio.
Различия между CPython и IronPython (и Jython в этом отношении, который применяет ту же концепцию, что и IronPython к JVM - Джим Хугунин был создателем Jython задолго до того, как он перешел в Microsoft, где он создал IronPython, оба проекта сейчас процветают). Главным образом в сборке мусора и в потоке: IronPython и Jython полагаются на свои базовые платформы (таким образом, вы получаете сбор мусора с разметкой и очисткой и бесплатную многопоточность), CPython выполняет свою собственную (так что это в основном GC с подсчетом ссылок, с mark-and-отключаться время от времени, чтобы разрешить циклы ссылок, и многопоточность затруднена глобальной блокировкой интерпретатора).
Хорошо закодированный скрипт Python не полагается на детали реализации, о которых идет речь (он никогда не предполагает, что GC происходит немедленно, никогда не предполагает, что операция является атомарной при многопоточности, за исключением немногих, таких как методы Queue.Queue, которые явно задокументированы как), но, конечно, в дикой природе есть множество скриптов, которые неаккуратны. Например:
data = open('x.txt').read()
это оставляет объект файла открытым, пока он не будет собран мусором; в среде подсчета ссылок сбор происходит немедленно (поэтому файл закрывается как можно скорее), в среде разметки и разметки это не так (поэтому процесс, использующий такие конструкции, часто ошибочно сохраняет некоторые файлы, возможно, много файлов, бесполезно открываются гораздо дольше, чем нужно, тратя ресурсы системы и т. д.).
Итак, правильное кодирование Python:
# needed in 2.5, unneeded but innocuous in 2.6
from __future__ import with_statement
with open('x.txt') as f: data = f.read()
который гарантирует немедленное закрытие файла в каждой реализации (with заявление очень, очень удобно таким образом;-).
Это не влияет на ваше изучение Python и не препятствует повторному использованию правильно кодированного кода Python, но если и когда вы захотите повторно использовать код Python с неаккуратным кодированием (особенно в долго работающем сервере, сервисе, процессе демона и т. Д.) в будущем вам, возможно, потребуется сделать некоторые меры по их ужесточению. Так, между прочим, будут ли люди, которые хотят использовать более новые и лучшие версии CPython, такие как Unladen Swallow &c, как только эти версии реализуют более совершенные механизмы сборки мусора, избавятся от GIL и других улучшений; надеюсь, это уже меняет "культуру" сообщества Python в сторону более правильного, менее неаккуратного кодирования, но, конечно, вокруг исчисляется несколько миллиардов строк старого неаккуратного кода, поэтому требуется некоторая осторожность;-).
Большинство сценариев Python отлично работают в IronPython.
Вот список пакетов и модулей, не включенных в IronPython в последней версии.
Пока ваш скрипт не полагается на них, он, скорее всего, будет работать без изменений. Тем не менее, большая часть "мощи" IronPython действительно вступает в игру, перенося ваши сценарии на использование классов платформы.NET вместо стандартной библиотеки python.