george
Python for .NET это модуль стандарного C-Python, позволяющий вызывать функции .net - библиотек. К примеру в .net есть pear-2-pear модуль (а-ля Napster), в Python нет,
вот можешь написать скрипт для обычного питона, который ее подымет и включит.

Я пока не въехал, как это вообще установить. В Readme сказано, что “Python for .NET is available as a source release and as a Windows installer for various versions of Python…”, но я в упор не вижу никаких “Windows installer” (setup.py тоже). И на кой там в архиве python.exe, если “это модуль стандарного C-Python”?

если разработка брошена на альфа-релизе, то всерьез использовать это не имеет смысла. кроме того два слоя интерпретации это неадекватное падение производительности даже по сравнению с обычным интерпретатором.

Если оно позволяет использовать классы .NET при сохранении всего остального функционала Python, использовать просто “между делом” (как ты сам привёл пример с pear-2-pear), то на “два слоя интерпретации” с “неадекватным падением производительности” можно смело начхать в очень многих случаях. Наверное.

Брошенная альфа — да, настораживает. Упоминания об IronPython в сопроводительных описаниях Python for .NET наводят на мысль, что разработчики сочли IronPython более перспективным, потому и бросили. Странно всё это. Судя по тому, до чего мы здесь додискутировались :), это получается неверный шаг, разве не так? Или же мы что-то не поняли?

>> это получается неверный шаг, разве не так?
именно на это и намекаю. есть тонкости, которые этой либе в любом случае будут не по зубам : шаблонные классы (как ты их выразишь и обратишься из Питона), методы, работа с асинхронными вызовами, и пр. если собираешься для .net лабать тут только 2 разумных выбора - boo и cobra. на меня могут конечно тюкать - мол, F#, Scheme, Haskell, Nemerle, - где то лучше. Могу доказать каждому на примерах, что все они и каждый в отдельно значительно проигрывают этим двум и в объеме кода и в его понятности при написании любой задачи.

Под “неверным шагом” я имел в виду прямо противоположное: разработчики зря забросили проект Python for .NET :).
Не знаю, но просто, например, такая ситуация: ты пишешь скрипт на стандартном Python. Есть дотнетовская сборка, написанная кем-то, которая решает какую-то нужную тебе проблему. Подключаешь её как любой модуль Python и пользуешься. Разве это плохо?

>> Разве это плохо?
это хорошо.

george
а меня могут конечно тюкать - мол, F#, Scheme, Haskell, Nemerle, - где то лучше. Могу доказать каждому на примерах, что все они и каждый в отдельно значительно проигрывают этим двум и в объеме кода и в его понятности при написании любой задачи.

Честно говоря я ковырялся немого с Ocaml и, больше, с Scheme. С их не .Net-реализациями. И они мне понравились, мне хотелось бы на них писать. Чем так плохи их .Net-реализации, что они значительно проигрывают .Net-реализациям питон? Или какие killer-фичи есть у Boo и Cobra?

igor.kaist
Лично я, не уверен в перспективе NET smile Версии платформ меняются, вроде с совместимостью проблемы есть. Да и не кроссплатформенно это…

А я уверен - вне зависимости от используемого ЯП ты получаешь наработки в виде огромной инфраструктуры. И тебе не надо подымать тему “Где взять библиотеку ххх” или “Как написать враппер для ууу” для моего любимого ЯП, а берешь и пользуешь библиотеку не задумываясь на чем она написана. А для кроссплатформенности есть mono :) Хотя, как по мне, не принципиально, что использовать. Была бы Java, лучше как платформа, получше можно было бы и Java. Хотя я на сей счет надежды не теряю.
А что касается совместимости на уровне всех РЕР-ов, то, я думаю, никто и не ставит такой цели. К примеру, работа с СУБД на Jython текущей стабильной версией игнорирует соответствующий РЕР стандартного Python.

По установке Python for .NET я нашёл только вот это:
http://mail.python.org/pipermail/pythondotnet/2008-May/000810.html
У меня творится точно такая же петрушка под Windows и я не знаю, что делать.

>>Чем так плохи их .Net-реализации, что они значительно проигрывают?
Scheme долго использовался в MIT в качестве универсального языка, за последние 5 лет они от него полностью отказались в пользу Питон. А boo лучше питона и в выразительности, и в краткости, в быстродействии. Ocaml, F#, Nemerle - близкородственные языки, ориентированные на функциональное программирование. Python, boo, cobra позволяют одинаково эффективно
писать как функционально, так и императивно, что в край важно, когда в системе должно быть и так, и так. А вообще, если сильно интересно, предложи компактную, но нетривиальную задачу, напиши ее на чем хошь, я на boo, сравним результат :-).

А boo действительно неплох, на первый взгляд. Надо будет его поковырять.