Это, к сожалению, проблема экосистемы питона под винду в целом, не специфичная для PTVS — если для установки пакета нужна сборка исходников на C, то начинаются танцы с бубном. В долгосрочной перспективе это должна исправить поддержка wheels в pip, но нужно еще, чтоба авторы пакетов делали бинарные колеса под винду — что проблематично в т.ч. потому, что многие сидят на линуксе или OS X. Мы пока еще думаем над тем, как этому поспособствовать — например, есть мысли о том, чтобы предоставлять VM в Azure с развернутой VS разных версий для авторов популярных пакетов, чтобы они могли там делать сборки. Или даже автоматический сервис по сборке, где авторы могли бы просто зарегистрировать свой пакет в PyPI, и автоматом получать билды при заливке новых версий.
Если все же дело доходит до локальной сборки, то отдельная головная боль — соотвествие версий компилятора. С 2.7 все хуже всего, т.к. эта ветка собиралась VS 2008, и на более новый компилятор не перейдет уже никогда — при этом, скачать компилятор сейчас сложно (он был в WinSDK и в VS Express, но эти старые версии скачать не так-то просто). Поэтому специально для 2.7 мы скооперировались с ребятами из VC++ team и выпустили дистрибутив VC++ 2008 (только сам компилятор, не IDE) специально для сборки пакетов при установке, и добавили его поддержку в setuptools. Таким образом, после его установки и обновления setuptools до последней версии, вы сможете, например, сделать pip install cython в 2.7, и все будет работать. Соответственно, все пакеты, которые зависят от Cython, тоже собираются.
Для 3.x ситуация немного другая — там ветка пока собирается VS 2010, но в 3.5 есть планы по переходу на новую версию компилятора, и мы активно пытаемся убедить сообщество в том, что это должен быть VS 14. Если все получится, то в дальнейшем можно будет использовать любую текущую версию VC++ (из VS Express, например) для сборки пакетов, т.к. начиная с 14, C runtime в VC будет совместимым в обе стороны.
Конкретно с numpy и scipy все еще сложнее, потому что там исходники не только на C, но еще и на Фортране, и куча зависимостей вроде MKL. Поэтому просто так их собрать локально не получится. В идеале, для них опять же нужны wheels, и мы всерьез думаем над тем, чтобы собирать их самим. Пока этого нет, для обычного питона можно скачать их отсюда — да, это инсталляторы, но их можно установить в virtualenv, если скормить путь к файлу в качестве аргумента для easy_install (это работает и в диалоге установки пакетов PTVS). Либо же можно взять Anaconda (или miniconda), и устанавливать бинарные пакеты через conda — у них в репозитарии есть и numpy, и scipy, и многое другое.
А про то, чего нет, потому и лучше читать документацию, что вы потом в коде не будете закладываться на вещи, которые сегодня есть, а завтра их нет :)
Нет, понятно, что иногда бывает интересно ковыряться в такого рода деталях, как и в различных вариантах undefined behavior в C++. Но это надо подавать соответствующим образом — не «C# это поддерживает», а «посмотрите, какой забавный глюк».
Подобное поведение при распаковке не является частью стандарта языка. Т.е., да, оно работает, но это незадокументированное расширение, и полагаться на него не стоит. Аналогично с приведением массивов, когда int[] можно успешно скастить к uint[] через object.
А синтаксис T? для Nullable<T> появился в той же версии языка, что и сам Nullable — C# 2.0. И, кстати говоря, вот эти два варианта дают один и тот же результат:
object x = (int)123;
object x = (int?)123;
Т.е. пакуется не Nullable, а его значение. Если спросить у полученного object его тип через GetType(), то вы получите int, а не Nullable. Если значения нет — после запаковки получается null. Поэтому такой вещи, как «распаковка из Nullable», просто не существует.
Вообще, про такие вещи лучше все-таки читать в спецификации, а не пытаться реверс-инжинирить их на кусках кода.
Сделать что-либо с рантаймами от других компиляторов сложно — собственно, в линуксе эта проблема решилась тем, что libc является, по сути, частью системного API, а не компилятора, а в винде исторически это не так, и каждый городит свой огород. Но можно попробовать навести порядок хотя бы в рамках VC++ (если вы используете плюсовые библиотеки, собранные другими компиляторами, у вас грабли начнутся задолго до передачи указателей). Над этим ребята из команды плюсов тоже активно работают. Есть надежда, что в дальнейшем и другие компиляторы тоже будут подхватывать этот системный рантайм вместо своего.
Со стороны команды PTVS (Steve Dower, который сейчас один из мэйнтейнеров питона под винду — из наших), мы активно пытаемся протолкнуть VC14 в качестве компилятора для Python 3.5 (третья ветка до сих пор собирается VC10), чтобы в дальнейшем голова о компиляторах и рантаймах у разработчиков больше не болела.
Частично эта проблема решается с поддержкой wheels — хотя, конечно, нужно еще, чтобы авторы модулей (ну, или кто-то другой) делали сборки колес под винду. По этому поводу есть некоторые мысли, вроде, например, сервиса автоматической сборки.
На данный момент я бы посоветовал ставить Anaconda (или Miniconda), и использовать их conda вместо pip — у них тоже есть бинарные пакеты, и их куда больше, чем бинарных колес на PyPI.
(Это не подколка, а серьезный вопрос — у меня в принципе есть список, но мне интересно, что именно вам там неудобно — поскольку моя команда в т.ч. занимается попытками как-то улучшить эту ситуацию; например.)
Её не так просто починить, как думается. Это ограничение много где прошито в API- интереса ради можете погрепать MAX_PATH в хедерах WinSDK. Везде, где оно встречается в какой-нибудь структуре, его изменение поломает бинарную совместимость. Т.е. старый софт заставить «просто работать» в общем случае не получится.
У вас, случайно, не стоит более ранняя версия Windows Management Framework? Судя по инструкции, её надо удалить руками. Посмотрите предпоследний комментарий здесь, там есть номера апдейтов:
Не совсем. Это проблема с любым кодом под винду, который не делает специальные приседания (\\?\ и т.д.) для обхода проблемы. Нода решила эту проблему радикально, прикрутив соответствующие костыли непосредствено в модуле fs, поэтому все тулзы, написанные на ноде же, получают её автоматически.
Навскидку из того, что имеет эту проблему — практически все стандартные консольные команды (напр, xcopy) и Проводник. Некоторое время назад была такая проблема с git под винду, но вроде бы вылечили.
Также эту проблему имеют практически все приложения на дотнете. Там все еще хуже, потому что, мало того, что стандартные классы для работы с файлами и путями никак не помогают это решать — но они еще и блокируют пути с \\?\, так что это невозможно обойти руками. Только P/Invoke. И, да, у них были на это веские причины, но сейчас от этого не легче. Как следствие, с длинными путями не работают все инструменты разработки, написанные на дотнете же. Это, в частности, MSBuild, и куча кода в VS.
Если все же дело доходит до локальной сборки, то отдельная головная боль — соотвествие версий компилятора. С 2.7 все хуже всего, т.к. эта ветка собиралась VS 2008, и на более новый компилятор не перейдет уже никогда — при этом, скачать компилятор сейчас сложно (он был в WinSDK и в VS Express, но эти старые версии скачать не так-то просто). Поэтому специально для 2.7 мы скооперировались с ребятами из VC++ team и выпустили дистрибутив VC++ 2008 (только сам компилятор, не IDE) специально для сборки пакетов при установке, и добавили его поддержку в setuptools. Таким образом, после его установки и обновления setuptools до последней версии, вы сможете, например, сделать pip install cython в 2.7, и все будет работать. Соответственно, все пакеты, которые зависят от Cython, тоже собираются.
Для 3.x ситуация немного другая — там ветка пока собирается VS 2010, но в 3.5 есть планы по переходу на новую версию компилятора, и мы активно пытаемся убедить сообщество в том, что это должен быть VS 14. Если все получится, то в дальнейшем можно будет использовать любую текущую версию VC++ (из VS Express, например) для сборки пакетов, т.к. начиная с 14, C runtime в VC будет совместимым в обе стороны.
Конкретно с numpy и scipy все еще сложнее, потому что там исходники не только на C, но еще и на Фортране, и куча зависимостей вроде MKL. Поэтому просто так их собрать локально не получится. В идеале, для них опять же нужны wheels, и мы всерьез думаем над тем, чтобы собирать их самим. Пока этого нет, для обычного питона можно скачать их отсюда — да, это инсталляторы, но их можно установить в virtualenv, если скормить путь к файлу в качестве аргумента для easy_install (это работает и в диалоге установки пакетов PTVS). Либо же можно взять Anaconda (или miniconda), и устанавливать бинарные пакеты через conda — у них в репозитарии есть и numpy, и scipy, и многое другое.
И вообще, что насчет разделения представления и модели?
А про то, чего нет, потому и лучше читать документацию, что вы потом в коде не будете закладываться на вещи, которые сегодня есть, а завтра их нет :)
Нет, понятно, что иногда бывает интересно ковыряться в такого рода деталях, как и в различных вариантах undefined behavior в C++. Но это надо подавать соответствующим образом — не «C# это поддерживает», а «посмотрите, какой забавный глюк».
А синтаксис T? для Nullable<T> появился в той же версии языка, что и сам Nullable — C# 2.0. И, кстати говоря, вот эти два варианта дают один и тот же результат:
Т.е. пакуется не Nullable, а его значение. Если спросить у полученного object его тип через GetType(), то вы получите int, а не Nullable. Если значения нет — после запаковки получается null. Поэтому такой вещи, как «распаковка из Nullable», просто не существует.
Вообще, про такие вещи лучше все-таки читать в спецификации, а не пытаться реверс-инжинирить их на кусках кода.
Сделать что-либо с рантаймами от других компиляторов сложно — собственно, в линуксе эта проблема решилась тем, что libc является, по сути, частью системного API, а не компилятора, а в винде исторически это не так, и каждый городит свой огород. Но можно попробовать навести порядок хотя бы в рамках VC++ (если вы используете плюсовые библиотеки, собранные другими компиляторами, у вас грабли начнутся задолго до передачи указателей). Над этим ребята из команды плюсов тоже активно работают. Есть надежда, что в дальнейшем и другие компиляторы тоже будут подхватывать этот системный рантайм вместо своего.
Со стороны команды PTVS (Steve Dower, который сейчас один из мэйнтейнеров питона под винду — из наших), мы активно пытаемся протолкнуть VC14 в качестве компилятора для Python 3.5 (третья ветка до сих пор собирается VC10), чтобы в дальнейшем голова о компиляторах и рантаймах у разработчиков больше не болела.
На данный момент я бы посоветовал ставить Anaconda (или Miniconda), и использовать их conda вместо pip — у них тоже есть бинарные пакеты, и их куда больше, чем бинарных колес на PyPI.
Ну и вы наверное видели этот сайт, но оставлю на всякий случай ссылку:
www.lfd.uci.edu/~gohlke/pythonlibs/
«Even Microsoft has decided to use Chocolatey's framework with the upcoming OneGet client!»
blogs.technet.com/b/windowsserver/archive/2014/04/03/windows-management-framework-v5-preview.aspx
«OneGet works with the community-based software repository called Chocolatey»
(Это не подколка, а серьезный вопрос — у меня в принципе есть список, но мне интересно, что именно вам там неудобно — поскольку моя команда в т.ч. занимается попытками как-то улучшить эту ситуацию; например.)
Вы издеваетесь, или просто настолько не в теме?
blogs.msdn.com/b/powershell/archive/2014/09/04/windows-management-framework-5-0-preview-september-2014-is-now-available.aspx
Навскидку из того, что имеет эту проблему — практически все стандартные консольные команды (напр, xcopy) и Проводник. Некоторое время назад была такая проблема с git под винду, но вроде бы вылечили.
Также эту проблему имеют практически все приложения на дотнете. Там все еще хуже, потому что, мало того, что стандартные классы для работы с файлами и путями никак не помогают это решать — но они еще и блокируют пути с \\?\, так что это невозможно обойти руками. Только P/Invoke. И, да, у них были на это веские причины, но сейчас от этого не легче. Как следствие, с длинными путями не работают все инструменты разработки, написанные на дотнете же. Это, в частности, MSBuild, и куча кода в VS.