Для установки PTVS достаточно запустить установщик для вашей версии VS: 2010, 2012, 2013 — или, если у вас нет VS (или есть только Express), то запустить комбинированный установщик для PTVS + VS Shell.
Дальше уже можно создавать проекты и писать код, даже без установленного интерпретатора Python (автодополнение будет использовать предварительно сгенерированную базу данных для наиболее часто используемого подмножества стандартной библиотеки). Когда вы запустите свой проект на выполнение в первый раз, вам предложат установить интерпретатор, и дадут прямую ссылку на скачку установщика для него.
Мы будем поддерживать все последующие версии CPython по мере их выхода. Для более ранних версий возможно добавление поддержки, если будет user demand — там на самом деле немного работы, из принципиальных для нас отличий только изменения во внутренней структуре данных строк и словарей. Но проблема еще в том, что нужны символы для интерпретатора — а питоновцы стали их публиковать только начиная с версии 2.7, поэтому даже если мы поддержим более старые версии, для смешанной отладки пользователям придется пересобирать интерпретатор.
Если вас интересует поддержка какой-то конкретной версии, заведите, пожалуйста, feature request на это в трекере.
Для других реализаций Python мы пока ничего конкретного не планируем — да и объем работы там куда больше — но первым кандидатом, если до этого дойдет, скорее всего, будет PyPy. Хотя, опять же, это зависит от того, за что именно проголосуют пользователи. Смешанная отладка как фича была #1 в трекере по голосам с большим отрывом, но без конкретики. Поэтому мы реализовали её так, как видели сами, но её дальнейшее развитие будет на 99% определяться вашим feedback.
Пока что из фич, связанных со смешанной отладкой, больше всего голосов за поддержку Cython.
Да, это я пропустил. Но посмотрите на комментарии к этой странице на wiki, и на репозиторий. Увы, не взлетело, хотя Enthought и старались.
Ну и понятно, что вкладывать столько сил в по сути ручные порты нативных расширений мало кто будет. А последняя версия IronClad была для 2.6 — я не уверен даже, что она будет работать с 2.7.
Смешанный отладчик работает только с CPython 2.7 или 3.3, при наличии PDB-файлов для python##.dll от вашего интерпретатора (по этой причине он не может работать с EPD/Canopy или ActivePython, пока они не опубликуют свои PDB).
Ограничения по функциональности: в ряде случаев — напимер, при остановке в нативном коде — доступен только ограниченный синтаксис для питоновских выражений в Watch и Immediate; нет отладочного REPL; нет conditional breakpoints. Первое является фундаментальным ограничением, хотя есть кое-какие идеи про то, как его смягчить. На все остальное просто не хватило времени (вся фича целиком писалась мной в одиночку, и на неё ушло 3 месяца чистого кодинга).
Основным сценарием там изначально являлась смешанная отладка Python и C++. Поддержка managed является побочным эффектом в силу гибкости архитектуры нового отладчика в VS 2012 (если вы реализовываете отладчик для своего рантайма, используя новый отладочный API, и корректно поддерживаете в нем смешанный режим, то вы автоматически работаете со всеми другими рантаймами, которые это делают — на сегодня это native, GPU, managed и JS). Но поддерживается только вариант вида «managed код загружает python##.dll», а не IronPython.
Для вашего сценария с IronPython вы можете попробовать воспользоваться чистым managed-отладчиком — он должен поддерживать IronPython на примитивном уровне, т.е. показывать локальные переменные в сыром виде, фреймы на стеке (с mangled именами методов), и корректно отображать их на исходники. Правда, как он будет себя вести при отсутствии имен файлов для кода, из которого сгенерирован IL, я не знаю.
Я думаю, в основном дело в сторонних библиотеках. Если в библиотеке есть какой-то нативный модуль, то она уже не будет работать под IronPython — а таких очень много, на самом деле. Те же NumPy/SciPy сразу же отпадают, а это изрядная доля разработчиков.
С другой стороны, скорость и многопоточность не столь интересны тем же веб-разработчикам, да и для большинства гуевых приложений это все не столь важно (а куски, где скорость критична, можно просто вынести в нативный код). Если же кому-то так нужна максимальная скорость питоновского кода, то ведь есть еще и PyPy — а он, пожалуй, будет и побыстрей, т.к. его JIT изначально заточен под питон.
Вот и получается, что на долю IronPython, по сути, остаются две ниши: динамический язык с возможностью использовать напрямую .NET-библиотеки, и скриптинг в .NET-приложениях. Как частный, но интересный случай, есть еще возможность делать гуй на питоне и WinForms или WPF — но, опять же, есть альтернатива в виде кроссплатформенного PyQt.
На какой версии PTVS? У нас был баг про проблемы с автодополнением с PyGtk, PyQt и PySide, но он был исправлен еще в 1.5.
Однако же я сейчас попробовал PyQt и PySide в бете — автозавершение представляет собой жалкое, душераздирающее зрелище. То, что я вижу, несколько отличается от того, что вы описали — классы в модулях видны, но они резолвятся как переменные со значением None, плюс в списках куча откровенного мусора. Я переоткрою баг с новой информацией — спасибо за наводку!
Я не буду оспаривать то, что развитие IronPython значительно замедлилось после того, как его отдали community. Это, в принципе, ожидаемо — над ним работает меньшее количество людей, и они должны это делать в свое свободное время. Но я бы не стал так быстро ставить над проектом крест. Посмотрим, что будет с обещанной поддержкой Python 3.x — в принципе, это на сегодня основная отсутствующая фича там.
Со стороны PTVS, мы будем продолжать в полной мере поддерживать IronPython, хотя наши приоритеты в первую очередь определяются предпочтениями пользователей — а у них наиболее популярным, с большим отрывом, является CPython.
Под «плохо» вы имеете в виду слишком малое количество возможностей, или какие-то баги при попытке их использовать?
Если последнее, то заведите, пожалуйста, баг — или опишите проблему здесь, и я сам это сделаю. Если первое, то проголосуйте за интересующие вас запросы по теме в трекере:
Однако же свежая альфа IronPython (2.7.4) вышла всего пару месяцев тому назад. И, кстати, они её добавили как пакет в NuGet, так что добавить в свое .NET-приложение скриптинг на питоне стало как нельзя проще.
Вы имеете в виду вот этот баг? Он все еще proposed, то есть им пока никто не занялся.
Но там речь шла о проблемах отладчика вообще, а не только в случае удаленной отладки. Видимо, gevent и мы где-то наступаем друг другу на пятки. Мы пока не изучали эту проблему детально.
У нас нет какой-либо специфичной интеграции с JS. Если в проекте есть .js-файлы, то вы получите стандартную функциональность используемой версии VS при работе с ними — насколько мне известно, из коробки поддержки JSHint там нет, но в галерее есть какое-то стороннее расширение для этого.
Дальше уже можно создавать проекты и писать код, даже без установленного интерпретатора Python (автодополнение будет использовать предварительно сгенерированную базу данных для наиболее часто используемого подмножества стандартной библиотеки). Когда вы запустите свой проект на выполнение в первый раз, вам предложат установить интерпретатор, и дадут прямую ссылку на скачку установщика для него.
Если вас интересует поддержка какой-то конкретной версии, заведите, пожалуйста, feature request на это в трекере.
Для других реализаций Python мы пока ничего конкретного не планируем — да и объем работы там куда больше — но первым кандидатом, если до этого дойдет, скорее всего, будет PyPy. Хотя, опять же, это зависит от того, за что именно проголосуют пользователи. Смешанная отладка как фича была #1 в трекере по голосам с большим отрывом, но без конкретики. Поэтому мы реализовали её так, как видели сами, но её дальнейшее развитие будет на 99% определяться вашим feedback.
Пока что из фич, связанных со смешанной отладкой, больше всего голосов за поддержку Cython.
Ну и понятно, что вкладывать столько сил в по сути ручные порты нативных расширений мало кто будет. А последняя версия IronClad была для 2.6 — я не уверен даже, что она будет работать с 2.7.
Ограничения по функциональности: в ряде случаев — напимер, при остановке в нативном коде — доступен только ограниченный синтаксис для питоновских выражений в Watch и Immediate; нет отладочного REPL; нет conditional breakpoints. Первое является фундаментальным ограничением, хотя есть кое-какие идеи про то, как его смягчить. На все остальное просто не хватило времени (вся фича целиком писалась мной в одиночку, и на неё ушло 3 месяца чистого кодинга).
Основным сценарием там изначально являлась смешанная отладка Python и C++. Поддержка managed является побочным эффектом в силу гибкости архитектуры нового отладчика в VS 2012 (если вы реализовываете отладчик для своего рантайма, используя новый отладочный API, и корректно поддерживаете в нем смешанный режим, то вы автоматически работаете со всеми другими рантаймами, которые это делают — на сегодня это native, GPU, managed и JS). Но поддерживается только вариант вида «managed код загружает python##.dll», а не IronPython.
Для вашего сценария с IronPython вы можете попробовать воспользоваться чистым managed-отладчиком — он должен поддерживать IronPython на примитивном уровне, т.е. показывать локальные переменные в сыром виде, фреймы на стеке (с mangled именами методов), и корректно отображать их на исходники. Правда, как он будет себя вести при отсутствии имен файлов для кода, из которого сгенерирован IL, я не знаю.
С другой стороны, скорость и многопоточность не столь интересны тем же веб-разработчикам, да и для большинства гуевых приложений это все не столь важно (а куски, где скорость критична, можно просто вынести в нативный код). Если же кому-то так нужна максимальная скорость питоновского кода, то ведь есть еще и PyPy — а он, пожалуй, будет и побыстрей, т.к. его JIT изначально заточен под питон.
Вот и получается, что на долю IronPython, по сути, остаются две ниши: динамический язык с возможностью использовать напрямую .NET-библиотеки, и скриптинг в .NET-приложениях. Как частный, но интересный случай, есть еще возможность делать гуй на питоне и WinForms или WPF — но, опять же, есть альтернатива в виде кроссплатформенного PyQt.
Однако же я сейчас попробовал PyQt и PySide в бете — автозавершение представляет собой жалкое, душераздирающее зрелище. То, что я вижу, несколько отличается от того, что вы описали — классы в модулях видны, но они резолвятся как переменные со значением None, плюс в списках куча откровенного мусора. Я переоткрою баг с новой информацией — спасибо за наводку!
Со стороны PTVS, мы будем продолжать в полной мере поддерживать IronPython, хотя наши приоритеты в первую очередь определяются предпочтениями пользователей — а у них наиболее популярным, с большим отрывом, является CPython.
Если последнее, то заведите, пожалуйста, баг — или опишите проблему здесь, и я сам это сделаю. Если первое, то проголосуйте за интересующие вас запросы по теме в трекере:
pytools.codeplex.com/workitem/177
pytools.codeplex.com/workitem/200
pytools.codeplex.com/workitem/201
pytools.codeplex.com/workitem/476
или, опять же, добавьте свои.
$attach Attaches the Visual Studio debugger to the REPL window process to enable debugging
Но там речь шла о проблемах отладчика вообще, а не только в случае удаленной отладки. Видимо, gevent и мы где-то наступаем друг другу на пятки. Мы пока не изучали эту проблему детально.