IronPython к Исходному сравнению Python. Что я могу ожидать от первого?
Ведущее устройство Толпы сделает, вещи как удостоверяющиеся толпы происходят, организовывая встречи планирования спринта, ретроспективы И т.д. Также, он будет в состоянии объяснить управлению, что делает команда и почему на членов команды нельзя незаконно охотиться прочь на другие проекты, пока спринт не заканчивается. Кроме того, нет действительно никаких определенных задач для Ведущего устройства Толпы. Таким образом, один человек должен легко быть в состоянии быть Ведущим устройством Толпы для 3 команд, и все еще иметь время в запасе, чтобы или делать работы типа управления (праздничные запросы, процедуры, присутствуя на скучных встречах с директорами или безотносительно), или быть свободным способствовать ресурсам разработки команды.
2 ответа
В вашей ситуации совершенно разумно изучать IronPython (тем более, что эта книга отлично помогает вам в этом!). У вас будет доступ практически ко всем функциям Python 2.5 (не уверен, когда IronPython обновится до версии Python 2.6, но 2.5 уже вполне можно использовать), плюс ко всем известным вам библиотекам и сборкам .Net и любовь, и такие инструменты, как надстройки Visual Studio.
Различия между CPython и IronPython (и Jython, если на то пошло, который применяет ту же концепцию, что и IronPython к JVM - Джим Хьюгунин был создателем Jython long до того, как он перешел в Microsoft, где он создал IronPython, оба проекта сейчас процветают) в основном занимаются сборкой мусора и потоками: IronPython и Jython полагаются на свои базовые платформы (так что вы получаете сборку мусора mark-and-sweep и бесплатную потоковую передачу), CPython катится самостоятельно (так что это в основном сборщик мусора с подсчетом ссылок, с меткой и очисткой время от времени для разрешения ссылочных циклов и потоковой передачей, затрудненной глобальным интерпретатором lock).
Хорошо написанный сценарий Python не полагается на детали реализации, о которых идет речь (он никогда не предполагает, что сборщик мусора происходит немедленно, никогда не предполагает, что операция является атомарной при потоковой передаче, за исключением немногих, таких как методы Queue.Queue, которые явно задокументированы), но, конечно же, существует множество сценариев, которые неаккуратны. Например:
data = open('x.txt').read()
это оставляет объект файла открытым до тех пор, пока он не будет собран в мусор; в среде со счетчиком ссылок сбор происходит немедленно (поэтому файл закрывается как можно скорее), в среде mark-and-sweep это не так (так что процесс, использующий такие конструкции, часто будет ошибочно держать некоторые файлы, может быть, много файлов, бесполезно открытыми гораздо дольше, чем нужно, тратя впустую системные ресурсы и т. д.)
Итак, правильное кодирование 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 очень удобен, что way; -).
Это не влияет на ваше изучение Python и не препятствует повторному использованию правильно написанного кода Python, но если и когда вы захотите повторно использовать небрежно закодированный код Python (особенно при длительном использовании server, service, daemon process и c) вам может потребоваться в будущем их ужесточить. Итак, кстати, люди, которые хотят использовать более новые и лучшие версии CPython, такие как Unladen Swallow и т. д., когда эти версии реализуют улучшенные механизмы сборки мусора, избавьтесь от GIL и других улучшений; Надеюсь, это уже меняет «культуру» сообщества Python в сторону более правильного и менее небрежного кодирования, но, конечно же, вокруг есть миллионы строк старого небрежного кода, поэтому требуется некоторая осторожность; -).
Большинство скриптов Python отлично работают в IronPython.
Вот список пакетов и модулей, не включенных в IronPython в последней версии.
Пока ваш сценарий не полагается на них, он, скорее всего, будет работать без изменений. Однако большая часть «мощи» IronPython действительно проявляется в переносе ваших скриптов на использование классов .NET Framework вместо стандартной библиотеки python.