Microsoft — мировой лидер в области ПО и ИТ-услуг
499,19
рейтинг
3 июля 2013 в 09:41

Разработка → Python Tools для Visual Studio, о новинках из первых рук

Эта статья написана Павлом Минаевым int19h — разработчиком из команды PTVS специально для публикации в нашем корпоративном блоге на Хабрахабре. Делитесь вашими впечатлениями в комментариях. Все отзывы будут переданы команде.

Здравствуйте! Я – разработчик из команды Python Tools for Visual Studio. На днях мы выпустили новую бета-версию нашего продукта, и, воспользовавшись поводом, в этот раз я хотел бы поподробнее рассказать о том, что из себя представляет PTVS, и что он может вам предложить.

image

Что такое PTVS?


Если вкратце, то Python Tools for Visual Studio (далее по тексту – PTVS), как, в общем-то, и следует из названия – бесплатное расширение для Visual Studio 2010 и выше, добавляющее в эту IDE полноценную поддержку Python. Поставив его себе, вы получаете редактирование кода на Питоне с подсветкой и продвинутым автозавершением, навигацией по коду, рефакторингом, отладкой, профилированием, и поддержкой Django с возможностью публиковать веб-сайты на Windows Azure в два клика. При этом поддерживаются все редакции Visual Studio, позволяющие установку расширений – как платные Professional, Premium и Ultimate, так и бесплатный Shell. В сочетании с последним, PTVS составляет полноценную бесплатную среду разработки на Python под Windows – и в этой версии мы сделали удобный комбинированный установщик для VS Shell + PTVS. Если же вы уже поставили себе Visual Studio 2013 Preview, то в диалоге New Project вас ждет приятный сюрприз:

clip_image001

Наш проект, в некотором роде, уникален для Microsoft. Открытыми (под Apache License 2.0) исходниками нынче никого не удивишь, но мы не просто публикуем исходники на CodePlex, но и приглашаем всех желающих совместно работать над проектом. Да-да, мы принимаем сторонний код!

И напоследок, поскольку с этим моментом чаще всего возникает путаница: PTVS – это не IronPython, и это не среда, ориентированная исключительно на IronPython. Мы поддерживаем практически все реализации Питона в той или иной степени – CPython, IronPython, Jython, PyPy, Stackless – но приоритетным является поддержка стандартного, и используемого большинством разработчиков на Питоне, интерпретатора CPython.

Далее я рассмотрю ряд наиболее интересных и уникальных возможностей PTVS более подробно.

Работа с кодом


Пожалуй, для любого разработчика, в первую очередь именно удобство работы с кодом является определяющем в выборе IDE. Именно поэтому продвинутый движок для разбора питоновского кода — на котором реализованны автодополнения, рефакторинг, символьный поиск и прочие ключевые фичи — был первым, что было создано в рамках проекта PTVS. С каждой новой версией мы улучшали качество разбора, и бета 2.0 – не исключение.

Простым автодополнением для динамически типизированных языков сегодня уже никого не удивишь, но многие редакторы «буксуют» на даже на тривиальных примерах использования динамических возможностей языка. Возьмем, например, вот такой код:

def f(x):
    def g(y):
        return x + y
    return g

a = f(1)(2)
b = f(3.0)(a)
c = f(u'a')(str(b))
d = (a, b, c)[input()]

Поскольку оператор сложения в Питоне полиморфен, то тип значения, возвращаемого g – и, как следствие, тип значений в a, b и c – зависит исключительно от типов передаваемых аргументов. Тип d наиболее сложен, поскольку он косвенно зависит от типов всех трех предыдущих переменных – при этом редактору нужно сначала собрать, а потом разобрать кортеж.

PTVS пытается однозначно определить тип при каждом конкретном вызове, учитывая ранее выведенные типы передаваемых аргументов. Вот подсказки и дополнения, которые выдаются в редакторе для различных переменных в этом коде:

clip_image002

clip_image003

clip_image004

clip_image005

Как видите, в последнем случае у переменной несколько потенциальных типов, и автодополнение отображает их все.

На результат вывода типов можно посмотреть и с другой стороны, если запросить подсказку для параметра функции в её теле:

clip_image006

Здесь собраны все типы аргументов, с которыми функция вызывается где-либо в коде – автодополнение для них в теле функции будет работать соответствующим образом. У этого есть интересное следствие – если вы используете TDD, и сначала пишете тесты для ваших функций и классов, а потом уже их реализации, то вы автоматически получите корректное автодополнение для всех параметров.

Помимо автодополнений, работает также и поиск объявлений и ссылок на переменные. Здесь у PTVS есть одно интересное дополнение – если переменная, с которой начался поиск, ссылается (или может ссылаться) на функции или классы, то в результатах поиска, кроме строки, на который этой переменной было присвоено значение, будут также и исходные объявления этих функций и классов – даже если значение было присвоено не напрямую. Например, если добавить к коду выше такие строки:

h = f if input() else f(a)
print h(b)

и выполнить команду Find All References на h, то получим следующий результат:

clip_image007

Как видите, в списке фигурирует функция g, поскольку именно её вернул вызов f(a). Разумеется, это отражается и в результатах автодополнения при попытке вызвать h – в предлагаемых вариантах сигнатур будут фигурировать все известные варианты для f и g:

clip_image008clip_image009

Отладка смешанного кода


Эксклюзив в бете 2.0 – такого больше нет нигде. Это тот самый случай, когда одна картинка стоит тысячи слов. Вот она:

clip_image010

На скриншоте – отладчик, присоединенный к программе на C#, которая загружает в себя CPython, который, в свою очередь, загружает модуль расширения, написанный на C++ — и все эти три вещи вызывают друг друга довольно-таки запутанным образом, который можно изучить в окне стека вызовов. Разумеется, можно создавать breakpoints во всех проектах, но самое главное, что дает такой комбинированный режим – возможность пошаговой отладки межъязыковых вызовов. Например, если выполнить команду Step In на строке питоновского кода, которая вызывает метод класса, реализованного в C++, то вы попадете в исходник этого метода. Точно так же это работает для кода на C++ или C#, вызывающего PyObject_CallObject для функции, написаной на Питоне. Поддерживаются также и вызовы нативного кода в обычных динамических библиотеках через ctypes.

Хотя на скриншоте показана одновременная отладка трех языков, на практике чаще всего дело ограничивается двумя – Питоном и C++ (или C) – либо это программа на Питоне, в которой используются модули расширения, либо программа на C++, использующая Питон в качестве скриптового языка. По этой причине мы добавили в отладчик ряд возможностей, доступных только для C/C++. Обратите внимание на окно Locals на скриншоте, и развернутое представление значения переменной a_natobj, которая ссылается на объект класса, реализованного на C++: одновременно с питоновским представлением объекта она показывает и C++-представление структуры, которая реализовывает его класс. Есть и зеркальное отображение питоновских объектов со стороны C++ — вот как выглядит то же самое окно Locals в функции frob:

clip_image011

Как видите, значения переменных, объявленных в C++ как PyObject (или какой-либо другой стандартный тип из Python API), отображают питоновские представления этих объектов одновременно с полями соответствующих C-структур.

Отладочный REPL


Наличие обычного REPL для Питона является стандартным в IDE для него, и PTVS не является исключением – разумеется, мы поддерживаем также и подсветку синтаксиса, и автодополнение (причем последнее, по возможности, работает напрямую со значениями в памяти, чтобы давать для них аккуратные подсказки). Но мы пошли дальше, и сделали поддержку «живого» REPL при отладке кода – то есть REPL работает непосредственно над данными в отлаживаемом процессе, позволяя вам на лету вычислять сложные выражения и переопределять классы и функции. Вот скриншот с отладочным REPL для первого примера из этой статьи:

clip_image012

Django и Windows Azure


PTVS поддерживает создание веб-приложений на Django, предоставляя подсветку синтаксиса, автозавершение кода и отладку для шаблонов отображений:

clip_image013

И, начиная с этой версии PTVS, созданные таким образом приложения можно опубликовать на веб-сайт в Windows Azure с легкостью, которая ранее была доступна только для ASP.NET:

clip_image014

Et voilà!

clip_image015

Да-да, веб-сайты Azure теперь поддерживают Python! Вы можете также использовать и другие возможности Azure – table service, blob service, service bus, storage queues и т.д. – в ваших приложениях на Питоне при помощи официального Windows Azure SDK для Python, над которым также работает наша команда. При этом SDK является кросс-платформенным: единственным требованием для него является Python 2.6 или выше.

Профилирование


И снова скриншоты скажут куда больше, чем слова:

clip_image016

clip_image017

clip_image018

… и многое другое!


Возможности PTVS не ограничиваются вышеперечисленным – у нас есть и другие интересные фичи, такие, как рефакторинг, работа с virtualenv и управление пакетами через pip и easy_install, удаленная отладка программ на Linux и OS X, поддержка IPython в REPL (с визуализацией графиков), и отладка и профилирование питоновского кода на MPI-кластерах. Вы можете почитать о них более подробно на странице документации проекта, или посмотреть обзорное видео.

Ваше мнение очень важно для нас


Нет, серьезно, оно действительно важно! У нас есть открытый баг-трекер, и мы всегда рады увидеть в нем баг-репорты и предложения от пользователей. Насчет предложений – это не пустой звук. Когда мы начинаем работать над новой версией, и решаем, что именно в ней будет, то первое, что мы делаем – открываем список feature requests в трекере, сортируем по голосам пользователей, и смотрим, что оказалось наверху. Так, в версии 2.0 мы реализовали пять фич из top 10 по голосам, в том числе три, которые были на первых трех местах. Если же вы хотите просто задать вопрос или обсудить что-то, это можно сделать на нашем форуме. И, разумеется, я буду рад ответить на любые ваши вопросы в комментариях к этой статье.
Автор: @XaocCPS
Microsoft
рейтинг 499,19
Microsoft — мировой лидер в области ПО и ИТ-услуг

Комментарии (49)

  • +14
    Отладка на стыке нескольких языков — это реально круто!
    А насчёт вывода типов, автодополнения и рефакторинга — как оно в сравнении с PyCharm? Кто попоробует, обязательно напишите.
    • 0
      С рефакторингом плохо все обстоит. Зато PTVS бесплатен и можно работать в привычной Visual Studio.
      • 0
        Под «плохо» вы имеете в виду слишком малое количество возможностей, или какие-то баги при попытке их использовать?

        Если последнее, то заведите, пожалуйста, баг — или опишите проблему здесь, и я сам это сделаю. Если первое, то проголосуйте за интересующие вас запросы по теме в трекере:

        pytools.codeplex.com/workitem/177
        pytools.codeplex.com/workitem/200
        pytools.codeplex.com/workitem/201
        pytools.codeplex.com/workitem/476

        или, опять же, добавьте свои.
        • 0
          Первое. Ок, спасибо
  • +1
    Eсть ли интеграция pyfalkes\pylint?
    • 0
      И заодно JSHint, раз уж речь о Django.
      • +1
        У нас нет какой-либо специфичной интеграции с JS. Если в проекте есть .js-файлы, то вы получите стандартную функциональность используемой версии VS при работе с ними — насколько мне известно, из коробки поддержки JSHint там нет, но в галерее есть какое-то стороннее расширение для этого.
    • +1
      Ответ Павла (сам он r/o):

      Нет, но это популярная просьба в трекере (https://pytools.codeplex.com/workitem/162), поэтому у нее есть большие шансы попасть в следующий релиз. Голосуйте за нее, и увеличьте их! 

      Из отдаленно имеющего отношение есть автоформатирование кода (Edit -> Advanced -> Format Document/Selection), которое по умолчанию работает в соответствии с PEP-8.
      • +12
        Такие люди не должны быть в readonly. Отправил инвайт.
        • +1
          спасибо большое!
  • 0
    >> удаленная отладка программ
    Все ещё не совместима с gevent?
    • +1
      Вы имеете в виду вот этот баг? Он все еще proposed, то есть им пока никто не занялся.

      Но там речь шла о проблемах отладчика вообще, а не только в случае удаленной отладки. Видимо, gevent и мы где-то наступаем друг другу на пятки. Мы пока не изучали эту проблему детально.
      • 0
        Да именно его
  • +1
    Python Tools развивается, а IronPython помирает… Эх. :(
    • +3
      Однако же свежая альфа IronPython (2.7.4) вышла всего пару месяцев тому назад. И, кстати, они её добавили как пакет в NuGet, так что добавить в свое .NET-приложение скриптинг на питоне стало как нельзя проще.
      • 0
        Это не развитие, это топтание на месте. 2.7.3 — год назад, 2.7.1 — два года назад. И сейчас это только альфа и только баг-фикс. Про Python 3 — ни слуху, ни духу. Задачи висят годами. Список рассылки практически вымер. Не создаётся впечатление живого проекта.
        • +2
          Для вашей информации IronPython 3 TODO
          blog.jdhardy.ca/2013/06/ironpython-3-todo.html
          • 0
            Что ж, будем надеяться на лучшее. :) Хотя изменение частоты постов в блоге в глаза сильно бросается…
        • +1
          Я не буду оспаривать то, что развитие IronPython значительно замедлилось после того, как его отдали community. Это, в принципе, ожидаемо — над ним работает меньшее количество людей, и они должны это делать в свое свободное время. Но я бы не стал так быстро ставить над проектом крест. Посмотрим, что будет с обещанной поддержкой Python 3.x — в принципе, это на сегодня основная отсутствующая фича там.

          Со стороны PTVS, мы будем продолжать в полной мере поддерживать IronPython, хотя наши приоритеты в первую очередь определяются предпочтениями пользователей — а у них наиболее популярным, с большим отрывом, является CPython.
          • 0
            Я от разработки чисто на питоне далёк — использую IronPython для скриптов внутри приложения, а отдельные приложения на питоне по сути не пишу. Вы не знаете, почему такое сильное предпочтение отдаётся CPython?

            IronPython бьёт CPython по скорости практически во всех тестах (сливается разве что на времени запуска и исключениях, хоть и не так, как раньше). IronPython не имеет такого маразма как GIL, то есть на порядки более приспособлен к многопоточной разработке, которая сейчас актуальна как никогда. Что все пользуются CPython, а не альтернативными реализациями — это дань традиции, или на то есть какие-то принципиальные причины? Если бы речь шла про *никсы, то я бы понимал нежелание полагаться на «M$» и мешанину технологий, но речь же про MS VS и MS Windows.
            • +1
              Я думаю, в основном дело в сторонних библиотеках. Если в библиотеке есть какой-то нативный модуль, то она уже не будет работать под IronPython — а таких очень много, на самом деле. Те же NumPy/SciPy сразу же отпадают, а это изрядная доля разработчиков.

              С другой стороны, скорость и многопоточность не столь интересны тем же веб-разработчикам, да и для большинства гуевых приложений это все не столь важно (а куски, где скорость критична, можно просто вынести в нативный код). Если же кому-то так нужна максимальная скорость питоновского кода, то ведь есть еще и PyPy — а он, пожалуй, будет и побыстрей, т.к. его JIT изначально заточен под питон.

              Вот и получается, что на долю IronPython, по сути, остаются две ниши: динамический язык с возможностью использовать напрямую .NET-библиотеки, и скриптинг в .NET-приложениях. Как частный, но интересный случай, есть еще возможность делать гуй на питоне и WinForms или WPF — но, опять же, есть альтернатива в виде кроссплатформенного PyQt.
              • 0
                Те же NumPy/SciPy сразу же отпадают, а это изрядная доля разработчиков.

                Э… В вики Python Tools же?

                IronClad помер, я так понимаю?
                • 0
                  Да, это я пропустил. Но посмотрите на комментарии к этой странице на wiki, и на репозиторий. Увы, не взлетело, хотя Enthought и старались.

                  Ну и понятно, что вкладывать столько сил в по сути ручные порты нативных расширений мало кто будет. А последняя версия IronClad была для 2.6 — я не уверен даже, что она будет работать с 2.7.
  • 0
    А команды с $, которые доступны в отладочном REPL (типа $frame) — специфичны для PTVS или взяты еще из какого-то тула?
    • 0
      Специфичны. Если приглядеться, там в описаниях иногда упоминается VS, например:

      $attach Attaches the Visual Studio debugger to the REPL window process to enable debugging
  • 0
    Не работает с библиотеками для Qt. PyQt4 не показывает в списке, но в комплите есть имя пакета, но больше ничего, с PySide чуть лучше, его определяет и показывает, а также модули, но не находит классов.
    Думал попробовать, т.к. расписали красиво, но пока останусь с PyCharm, т.к. Qt мне критично нужно.
    • +1
      На какой версии PTVS? У нас был баг про проблемы с автодополнением с PyGtk, PyQt и PySide, но он был исправлен еще в 1.5.

      Однако же я сейчас попробовал PyQt и PySide в бете — автозавершение представляет собой жалкое, душераздирающее зрелище. То, что я вижу, несколько отличается от того, что вы описали — классы в модулях видны, но они резолвятся как переменные со значением None, плюс в списках куча откровенного мусора. Я переоткрою баг с новой информацией — спасибо за наводку!
      • 0
        Спасибо. У меня только непонятный мусор.
        • +1
          Багу с мусором нашли, фикс будет в RC.

          Попутно еще немного поигрался с PySide. С фиксом code completion в PTVS для него работает на достаточно примитивном уровне — есть списки модулей, в них классы, и в классах члены. Но никакой информации о типах аргументов и возврата уже нет, что и понятно — все функции определены в нативных модулях, поэтому про type inference можно забыть. Попробовал в PyCharm — там вроде бы та же картина.

          В связи с этим возник вопрос: есть ли интерес в добавлении фичи, которая позволила бы подключать внешную информацию о типах для произвольных модулей, которую можно было бы автоматически генерировать для библиотек типа PySide/PyQt (т.к. там исходный API типизирован), или писать руками для других библиотек?
          • 0
            Было бы неплохо, если и типы говорило, но мне не слишком критично. Большинства функций я и так знаю прототипы, а те, что не знаю могу с легкостью посмотреть на сайте, по нажатию Shift+F1 на теле функции переходит в доку прямо на ее описание. Если сделаете также, то и так хорошо.

            Спасибо! RC наверно ждать не скоро? )
            • +1
              Проблема в отсутствии типов в том, что тогда пропадает автодополнение на возвращаемых значениях. Т.е. скажем:

              checkbox = qtgui.QCheckBox() # ok
              parent = checkbox.parentWidget() # автодополнение показывает метод, но не его параметры/результат
              parent. # тип parent неизвестен, не показывается ничего
              


              RC будет нескоро :) но багфиксы мы выкладываем в репозиторий на CodePlex сразу, как только они реализуются, так что он там будет в понедельник (сейчас праздники и все в разъездах). Зависимости для сборки у нас минимальны — для ядра продукта, если не собирать всякие там HPC или Kinect, нужен только VS SDK.
              • 0
                Это плохо (

                Я как-то и забыл, что это опенсорс ) тогда жду когда будит коммит.
                • 0
                  Извините за задержку — фикс был, но мы долго чинили скрипты, которыми исходники выкладываются на CodePlex. Теперь все там.
  • 0
    У меня не завелось почему-то :(. В студии не появился новый тип проекта. На всякий случай даже Python переставил — бесполезно.
    • 0
      У вас, случайно, не VS Express?
      • 0
        Нет. Запустил установку ещё раз, ткнул repair, после этого ожило. Не знаю, с чем было связано.
  • +1
    Очень интересная и удобная штука. Жаль только одно — что всё это только на Windows доступно.
  • 0
    Отладка смешанного кода — это очень интересно. У меня в приложении на C# на ходу генерируется питоноский код и выполняется с помощью IronPython — я смогу отлаживать сгенерированный код, или для отладки обязательно нужны файлы? Какие реализации питона поддерживаются? Вообще, какие требования и ограничения для отладки смешанного кода?
    • +1
      Смешанный отладчик работает только с 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, я не знаю.
      • 0
        Поддержка будет ограничиваться CPython этих конкретных версий, или есть планы по поддержке других реализаций?
        • +2
          Мы будем поддерживать все последующие версии CPython по мере их выхода. Для более ранних версий возможно добавление поддержки, если будет user demand — там на самом деле немного работы, из принципиальных для нас отличий только изменения во внутренней структуре данных строк и словарей. Но проблема еще в том, что нужны символы для интерпретатора — а питоновцы стали их публиковать только начиная с версии 2.7, поэтому даже если мы поддержим более старые версии, для смешанной отладки пользователям придется пересобирать интерпретатор.

          Если вас интересует поддержка какой-то конкретной версии, заведите, пожалуйста, feature request на это в трекере.

          Для других реализаций Python мы пока ничего конкретного не планируем — да и объем работы там куда больше — но первым кандидатом, если до этого дойдет, скорее всего, будет PyPy. Хотя, опять же, это зависит от того, за что именно проголосуют пользователи. Смешанная отладка как фича была #1 в трекере по голосам с большим отрывом, но без конкретики. Поэтому мы реализовали её так, как видели сами, но её дальнейшее развитие будет на 99% определяться вашим feedback.

          Пока что из фич, связанных со смешанной отладкой, больше всего голосов за поддержку Cython.
  • 0
    Хотелось бы видеть в статье ссылку «How to ...», как установить и начать пользоваться Python + Python Tools.
    • +2
      1. Скачиваем и устанавливаем MSVS 2010/2012/2013 (не Express)
      2. Скачиваем и устанавливаем Python 2.7/3.3 x86/amd64
      3. Скачиваем и устанавливаем PTVS 2.0 beta
      4. Запускаем VS выбираем в меню Файл->Создать->Проект, в открывшемся окне выбираешь Другие языки-
      >Python и выбираешь нужный шаблон
      5. Profit!
      • 0
        Второй пункт можно пропустить, PTVS потом сам отправить качать питон, когда он будет нужен :)
        • 0
          В теории все кто хочет попробовать PTVS уже писали(шут) на Python, т.ч. он должен и так быть у них установлен.
  • +1
    Для установки PTVS достаточно запустить установщик для вашей версии VS: 2010, 2012, 2013 — или, если у вас нет VS (или есть только Express), то запустить комбинированный установщик для PTVS + VS Shell.

    Дальше уже можно создавать проекты и писать код, даже без установленного интерпретатора Python (автодополнение будет использовать предварительно сгенерированную базу данных для наиболее часто используемого подмножества стандартной библиотеки). Когда вы запустите свой проект на выполнение в первый раз, вам предложат установить интерпретатор, и дадут прямую ссылку на скачку установщика для него.
  • 0
    Будет ли поддержка 2008 «Студии»?
    К сожалению, есть ещё люди, которые в ней работают.
    • 0
      Я думаю не стоит надеяться. Там совсем другая система расширений оболочки, вроде бы. Вряд ли кто код конец 2013 года будет начинать делать считай с нуля новое расширение под студию 5-летней давности.
      • +1
        Она не то что бы принципиально другая, но в десятке было достаточно много новых API, на которые мы завязались. Кроме того, в коде также активно используются возможности .NET 4 (например, TPL), а для 2008 нужно писать на 3.5 SP1.

        Так что в итоге, да, овчинка выделки не стоит. Но если нет необходимости работать с многоязыковыми проектами, то как вариант всегда есть бесплатный VS Shell.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка