Comments 49
Отладка на стыке нескольких языков — это реально круто!
А насчёт вывода типов, автодополнения и рефакторинга — как оно в сравнении с PyCharm? Кто попоробует, обязательно напишите.
А насчёт вывода типов, автодополнения и рефакторинга — как оно в сравнении с PyCharm? Кто попоробует, обязательно напишите.
С рефакторингом плохо все обстоит. Зато PTVS бесплатен и можно работать в привычной Visual Studio.
Под «плохо» вы имеете в виду слишком малое количество возможностей, или какие-то баги при попытке их использовать?
Если последнее, то заведите, пожалуйста, баг — или опишите проблему здесь, и я сам это сделаю. Если первое, то проголосуйте за интересующие вас запросы по теме в трекере:
pytools.codeplex.com/workitem/177
pytools.codeplex.com/workitem/200
pytools.codeplex.com/workitem/201
pytools.codeplex.com/workitem/476
или, опять же, добавьте свои.
Если последнее, то заведите, пожалуйста, баг — или опишите проблему здесь, и я сам это сделаю. Если первое, то проголосуйте за интересующие вас запросы по теме в трекере:
pytools.codeplex.com/workitem/177
pytools.codeplex.com/workitem/200
pytools.codeplex.com/workitem/201
pytools.codeplex.com/workitem/476
или, опять же, добавьте свои.
Eсть ли интеграция pyfalkes\pylint?
И заодно JSHint, раз уж речь о Django.
У нас нет какой-либо специфичной интеграции с JS. Если в проекте есть .js-файлы, то вы получите стандартную функциональность используемой версии VS при работе с ними — насколько мне известно, из коробки поддержки JSHint там нет, но в галерее есть какое-то стороннее расширение для этого.
Ответ Павла (сам он r/o):
Нет, но это популярная просьба в трекере (https://pytools.codeplex.com/workitem/162), поэтому у нее есть большие шансы попасть в следующий релиз. Голосуйте за нее, и увеличьте их!
Из отдаленно имеющего отношение есть автоформатирование кода (Edit -> Advanced -> Format Document/Selection), которое по умолчанию работает в соответствии с PEP-8.
Нет, но это популярная просьба в трекере (https://pytools.codeplex.com/workitem/162), поэтому у нее есть большие шансы попасть в следующий релиз. Голосуйте за нее, и увеличьте их!
Из отдаленно имеющего отношение есть автоформатирование кода (Edit -> Advanced -> Format Document/Selection), которое по умолчанию работает в соответствии с PEP-8.
>> удаленная отладка программ
Все ещё не совместима с gevent?
Все ещё не совместима с gevent?
Вы имеете в виду вот этот баг? Он все еще proposed, то есть им пока никто не занялся.
Но там речь шла о проблемах отладчика вообще, а не только в случае удаленной отладки. Видимо, gevent и мы где-то наступаем друг другу на пятки. Мы пока не изучали эту проблему детально.
Но там речь шла о проблемах отладчика вообще, а не только в случае удаленной отладки. Видимо, gevent и мы где-то наступаем друг другу на пятки. Мы пока не изучали эту проблему детально.
Python Tools развивается, а IronPython помирает… Эх. :(
Однако же свежая альфа IronPython (2.7.4) вышла всего пару месяцев тому назад. И, кстати, они её добавили как пакет в NuGet, так что добавить в свое .NET-приложение скриптинг на питоне стало как нельзя проще.
Это не развитие, это топтание на месте. 2.7.3 — год назад, 2.7.1 — два года назад. И сейчас это только альфа и только баг-фикс. Про Python 3 — ни слуху, ни духу. Задачи висят годами. Список рассылки практически вымер. Не создаётся впечатление живого проекта.
Для вашей информации IronPython 3 TODO
blog.jdhardy.ca/2013/06/ironpython-3-todo.html
blog.jdhardy.ca/2013/06/ironpython-3-todo.html
Я не буду оспаривать то, что развитие IronPython значительно замедлилось после того, как его отдали community. Это, в принципе, ожидаемо — над ним работает меньшее количество людей, и они должны это делать в свое свободное время. Но я бы не стал так быстро ставить над проектом крест. Посмотрим, что будет с обещанной поддержкой Python 3.x — в принципе, это на сегодня основная отсутствующая фича там.
Со стороны PTVS, мы будем продолжать в полной мере поддерживать IronPython, хотя наши приоритеты в первую очередь определяются предпочтениями пользователей — а у них наиболее популярным, с большим отрывом, является CPython.
Со стороны PTVS, мы будем продолжать в полной мере поддерживать IronPython, хотя наши приоритеты в первую очередь определяются предпочтениями пользователей — а у них наиболее популярным, с большим отрывом, является CPython.
Я от разработки чисто на питоне далёк — использую IronPython для скриптов внутри приложения, а отдельные приложения на питоне по сути не пишу. Вы не знаете, почему такое сильное предпочтение отдаётся CPython?
IronPython бьёт CPython по скорости практически во всех тестах (сливается разве что на времени запуска и исключениях, хоть и не так, как раньше). IronPython не имеет такого маразма как GIL, то есть на порядки более приспособлен к многопоточной разработке, которая сейчас актуальна как никогда. Что все пользуются CPython, а не альтернативными реализациями — это дань традиции, или на то есть какие-то принципиальные причины? Если бы речь шла про *никсы, то я бы понимал нежелание полагаться на «M$» и мешанину технологий, но речь же про MS VS и MS Windows.
IronPython бьёт CPython по скорости практически во всех тестах (сливается разве что на времени запуска и исключениях, хоть и не так, как раньше). IronPython не имеет такого маразма как GIL, то есть на порядки более приспособлен к многопоточной разработке, которая сейчас актуальна как никогда. Что все пользуются CPython, а не альтернативными реализациями — это дань традиции, или на то есть какие-то принципиальные причины? Если бы речь шла про *никсы, то я бы понимал нежелание полагаться на «M$» и мешанину технологий, но речь же про MS VS и MS Windows.
Я думаю, в основном дело в сторонних библиотеках. Если в библиотеке есть какой-то нативный модуль, то она уже не будет работать под IronPython — а таких очень много, на самом деле. Те же NumPy/SciPy сразу же отпадают, а это изрядная доля разработчиков.
С другой стороны, скорость и многопоточность не столь интересны тем же веб-разработчикам, да и для большинства гуевых приложений это все не столь важно (а куски, где скорость критична, можно просто вынести в нативный код). Если же кому-то так нужна максимальная скорость питоновского кода, то ведь есть еще и PyPy — а он, пожалуй, будет и побыстрей, т.к. его JIT изначально заточен под питон.
Вот и получается, что на долю IronPython, по сути, остаются две ниши: динамический язык с возможностью использовать напрямую .NET-библиотеки, и скриптинг в .NET-приложениях. Как частный, но интересный случай, есть еще возможность делать гуй на питоне и WinForms или WPF — но, опять же, есть альтернатива в виде кроссплатформенного PyQt.
С другой стороны, скорость и многопоточность не столь интересны тем же веб-разработчикам, да и для большинства гуевых приложений это все не столь важно (а куски, где скорость критична, можно просто вынести в нативный код). Если же кому-то так нужна максимальная скорость питоновского кода, то ведь есть еще и PyPy — а он, пожалуй, будет и побыстрей, т.к. его JIT изначально заточен под питон.
Вот и получается, что на долю IronPython, по сути, остаются две ниши: динамический язык с возможностью использовать напрямую .NET-библиотеки, и скриптинг в .NET-приложениях. Как частный, но интересный случай, есть еще возможность делать гуй на питоне и WinForms или WPF — но, опять же, есть альтернатива в виде кроссплатформенного PyQt.
Те же NumPy/SciPy сразу же отпадают, а это изрядная доля разработчиков.
Э… В вики Python Tools же?
IronClad помер, я так понимаю?
Да, это я пропустил. Но посмотрите на комментарии к этой странице на wiki, и на репозиторий. Увы, не взлетело, хотя Enthought и старались.
Ну и понятно, что вкладывать столько сил в по сути ручные порты нативных расширений мало кто будет. А последняя версия IronClad была для 2.6 — я не уверен даже, что она будет работать с 2.7.
Ну и понятно, что вкладывать столько сил в по сути ручные порты нативных расширений мало кто будет. А последняя версия IronClad была для 2.6 — я не уверен даже, что она будет работать с 2.7.
А команды с $, которые доступны в отладочном REPL (типа $frame) — специфичны для PTVS или взяты еще из какого-то тула?
Не работает с библиотеками для Qt. PyQt4 не показывает в списке, но в комплите есть имя пакета, но больше ничего, с PySide чуть лучше, его определяет и показывает, а также модули, но не находит классов.
Думал попробовать, т.к. расписали красиво, но пока останусь с PyCharm, т.к. Qt мне критично нужно.
Думал попробовать, т.к. расписали красиво, но пока останусь с PyCharm, т.к. Qt мне критично нужно.
На какой версии PTVS? У нас был баг про проблемы с автодополнением с PyGtk, PyQt и PySide, но он был исправлен еще в 1.5.
Однако же я сейчас попробовал PyQt и PySide в бете — автозавершение представляет собой жалкое, душераздирающее зрелище. То, что я вижу, несколько отличается от того, что вы описали — классы в модулях видны, но они резолвятся как переменные со значением None, плюс в списках куча откровенного мусора. Я переоткрою баг с новой информацией — спасибо за наводку!
Однако же я сейчас попробовал PyQt и PySide в бете — автозавершение представляет собой жалкое, душераздирающее зрелище. То, что я вижу, несколько отличается от того, что вы описали — классы в модулях видны, но они резолвятся как переменные со значением None, плюс в списках куча откровенного мусора. Я переоткрою баг с новой информацией — спасибо за наводку!
Спасибо. У меня только непонятный мусор.
Багу с мусором нашли, фикс будет в RC.
Попутно еще немного поигрался с PySide. С фиксом code completion в PTVS для него работает на достаточно примитивном уровне — есть списки модулей, в них классы, и в классах члены. Но никакой информации о типах аргументов и возврата уже нет, что и понятно — все функции определены в нативных модулях, поэтому про type inference можно забыть. Попробовал в PyCharm — там вроде бы та же картина.
В связи с этим возник вопрос: есть ли интерес в добавлении фичи, которая позволила бы подключать внешную информацию о типах для произвольных модулей, которую можно было бы автоматически генерировать для библиотек типа PySide/PyQt (т.к. там исходный API типизирован), или писать руками для других библиотек?
Попутно еще немного поигрался с PySide. С фиксом code completion в PTVS для него работает на достаточно примитивном уровне — есть списки модулей, в них классы, и в классах члены. Но никакой информации о типах аргументов и возврата уже нет, что и понятно — все функции определены в нативных модулях, поэтому про type inference можно забыть. Попробовал в PyCharm — там вроде бы та же картина.
В связи с этим возник вопрос: есть ли интерес в добавлении фичи, которая позволила бы подключать внешную информацию о типах для произвольных модулей, которую можно было бы автоматически генерировать для библиотек типа PySide/PyQt (т.к. там исходный API типизирован), или писать руками для других библиотек?
Было бы неплохо, если и типы говорило, но мне не слишком критично. Большинства функций я и так знаю прототипы, а те, что не знаю могу с легкостью посмотреть на сайте, по нажатию Shift+F1 на теле функции переходит в доку прямо на ее описание. Если сделаете также, то и так хорошо.
Спасибо! RC наверно ждать не скоро? )
Спасибо! RC наверно ждать не скоро? )
Проблема в отсутствии типов в том, что тогда пропадает автодополнение на возвращаемых значениях. Т.е. скажем:
RC будет нескоро :) но багфиксы мы выкладываем в репозиторий на CodePlex сразу, как только они реализуются, так что он там будет в понедельник (сейчас праздники и все в разъездах). Зависимости для сборки у нас минимальны — для ядра продукта, если не собирать всякие там HPC или Kinect, нужен только VS SDK.
checkbox = qtgui.QCheckBox() # ok
parent = checkbox.parentWidget() # автодополнение показывает метод, но не его параметры/результат
parent. # тип parent неизвестен, не показывается ничего
RC будет нескоро :) но багфиксы мы выкладываем в репозиторий на CodePlex сразу, как только они реализуются, так что он там будет в понедельник (сейчас праздники и все в разъездах). Зависимости для сборки у нас минимальны — для ядра продукта, если не собирать всякие там HPC или Kinect, нужен только VS SDK.
У меня не завелось почему-то :(. В студии не появился новый тип проекта. На всякий случай даже Python переставил — бесполезно.
Очень интересная и удобная штука. Жаль только одно — что всё это только на Windows доступно.
Отладка смешанного кода — это очень интересно. У меня в приложении на C# на ходу генерируется питоноский код и выполняется с помощью IronPython — я смогу отлаживать сгенерированный код, или для отладки обязательно нужны файлы? Какие реализации питона поддерживаются? Вообще, какие требования и ограничения для отладки смешанного кода?
Смешанный отладчик работает только с 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, я не знаю.
Ограничения по функциональности: в ряде случаев — напимер, при остановке в нативном коде — доступен только ограниченный синтаксис для питоновских выражений в 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, я не знаю.
Поддержка будет ограничиваться CPython этих конкретных версий, или есть планы по поддержке других реализаций?
Мы будем поддерживать все последующие версии CPython по мере их выхода. Для более ранних версий возможно добавление поддержки, если будет user demand — там на самом деле немного работы, из принципиальных для нас отличий только изменения во внутренней структуре данных строк и словарей. Но проблема еще в том, что нужны символы для интерпретатора — а питоновцы стали их публиковать только начиная с версии 2.7, поэтому даже если мы поддержим более старые версии, для смешанной отладки пользователям придется пересобирать интерпретатор.
Если вас интересует поддержка какой-то конкретной версии, заведите, пожалуйста, feature request на это в трекере.
Для других реализаций Python мы пока ничего конкретного не планируем — да и объем работы там куда больше — но первым кандидатом, если до этого дойдет, скорее всего, будет PyPy. Хотя, опять же, это зависит от того, за что именно проголосуют пользователи. Смешанная отладка как фича была #1 в трекере по голосам с большим отрывом, но без конкретики. Поэтому мы реализовали её так, как видели сами, но её дальнейшее развитие будет на 99% определяться вашим feedback.
Пока что из фич, связанных со смешанной отладкой, больше всего голосов за поддержку Cython.
Если вас интересует поддержка какой-то конкретной версии, заведите, пожалуйста, feature request на это в трекере.
Для других реализаций Python мы пока ничего конкретного не планируем — да и объем работы там куда больше — но первым кандидатом, если до этого дойдет, скорее всего, будет PyPy. Хотя, опять же, это зависит от того, за что именно проголосуют пользователи. Смешанная отладка как фича была #1 в трекере по голосам с большим отрывом, но без конкретики. Поэтому мы реализовали её так, как видели сами, но её дальнейшее развитие будет на 99% определяться вашим feedback.
Пока что из фич, связанных со смешанной отладкой, больше всего голосов за поддержку Cython.
Хотелось бы видеть в статье ссылку «How to ...», как установить и начать пользоваться Python + Python Tools.
1. Скачиваем и устанавливаем MSVS 2010/2012/2013 (не Express)
2. Скачиваем и устанавливаем Python 2.7/3.3 x86/amd64
3. Скачиваем и устанавливаем PTVS 2.0 beta
4. Запускаем VS выбираем в меню Файл->Создать->Проект, в открывшемся окне выбираешь Другие языки-
>Python и выбираешь нужный шаблон
5. Profit!
2. Скачиваем и устанавливаем Python 2.7/3.3 x86/amd64
3. Скачиваем и устанавливаем PTVS 2.0 beta
4. Запускаем VS выбираем в меню Файл->Создать->Проект, в открывшемся окне выбираешь Другие языки-
>Python и выбираешь нужный шаблон
5. Profit!
Для установки PTVS достаточно запустить установщик для вашей версии VS: 2010, 2012, 2013 — или, если у вас нет VS (или есть только Express), то запустить комбинированный установщик для PTVS + VS Shell.
Дальше уже можно создавать проекты и писать код, даже без установленного интерпретатора Python (автодополнение будет использовать предварительно сгенерированную базу данных для наиболее часто используемого подмножества стандартной библиотеки). Когда вы запустите свой проект на выполнение в первый раз, вам предложат установить интерпретатор, и дадут прямую ссылку на скачку установщика для него.
Дальше уже можно создавать проекты и писать код, даже без установленного интерпретатора Python (автодополнение будет использовать предварительно сгенерированную базу данных для наиболее часто используемого подмножества стандартной библиотеки). Когда вы запустите свой проект на выполнение в первый раз, вам предложат установить интерпретатор, и дадут прямую ссылку на скачку установщика для него.
Будет ли поддержка 2008 «Студии»?
К сожалению, есть ещё люди, которые в ней работают.
К сожалению, есть ещё люди, которые в ней работают.
Я думаю не стоит надеяться. Там совсем другая система расширений оболочки, вроде бы. Вряд ли кто код конец 2013 года будет начинать делать считай с нуля новое расширение под студию 5-летней давности.
Она не то что бы принципиально другая, но в десятке было достаточно много новых API, на которые мы завязались. Кроме того, в коде также активно используются возможности .NET 4 (например, TPL), а для 2008 нужно писать на 3.5 SP1.
Так что в итоге, да, овчинка выделки не стоит. Но если нет необходимости работать с многоязыковыми проектами, то как вариант всегда есть бесплатный VS Shell.
Так что в итоге, да, овчинка выделки не стоит. Но если нет необходимости работать с многоязыковыми проектами, то как вариант всегда есть бесплатный VS Shell.
Sign up to leave a comment.
Python Tools для Visual Studio, о новинках из первых рук