".NET"不是一种语言.也许是Python对C#或Python/Django对C#/ASP.NET(或者 Select 任何你想要的"webwork"；Python和".NET"都有很多不同的解决方案， Select bat的Django或MVC2可能会严重限制更好的可行选项).作为Python与".NET"的对比:有IronPython个(Python"in.NET")
我会考虑:Developer comfort使用一种语言，如果它们在Python和".NET"中相等，那么我会考虑开发周转时间，并 Select 将这一点最小化的语言/"网络工作"(同样，它不需要是以前的限制).
虽然单元/集成测试对于任何[大型]项目都是必须的，但我发现statically typed language(C#/F#)可以减少与类型相关的"愚蠢错误"的数量.
开放竞争环境:-)
Edit for comment:
那么你只是在比较语言.
在这种情况下，C#是一种非常枯燥的命令式静态类型语言，具有基于单一继承/接口类的OO(但有一些比Java更巧妙的技巧，Java只是一个彻头彻尾的石器时代).这是the same basic type of OO as Python has，不包括静态/动态位both languages are strongly typed(机制不同，但最终结果在语言谱中非常相似).实际上，python有MI，但在python中，使用'lambda'关键字似乎不太被接受，而且由于python是动态类型化的，因此没有编译时支持确定接口/类型契约(然而，有些模块试图提供这种功能).
这不是范式的转变.这里的一些关键字，那里的大括号，需要说明你指的是什么类型，那里是一个不同的基库……不同的环境(您必须进行一些斗争才能获得REPL，但这在VS中是可行的.)开发人员如何喜欢/学习/使用它则是另一回事.虽然我以前确实调用了C#命令性，但是很高兴看到添加了一些"类似函数"的特性，比如LINQ/IEnumerable扩展和不带委托的闭包，即使基本的C#语法非常过程化，也很像python(for表达式、嵌套函数、语句/表达式分割).
虽然新的"动态"确实模糊了界限(它很少有很好的用处--在以前的C#版本中可能不得不退回到反射的几乎所有相同的地方--这不是真的，但问题是它通常是"错误的方式"，除非在少数情况下恰好是"最好的/唯一的方式")，"var"不是这样的.也就是说，"var"变量的类型是known at compile-time和has nothing to do with dynamic typing；它都是类型推断.一些语言，如F#/sml和haskell，在保留静电类型的同时，拥有强大得多的类型推断，消除了"所有那些难看的类型声明"的需要(尽管显式注释允许的类型或类型集可以使意图更清晰).
就我个人而言，everything else aside，我会使用静态类型的语言.我说的不是C#(我绝对不是说Java！)，而是statically typed languages can push type errors to the top and require up-front explicit contracts(这对我来说是一个很大的胜利).虽然你确实错过了一些巧妙的动态技巧，但几乎总是有更好的方法来用目标语言执行同样的动作--你只需从目标语言的Angular 考虑，用螺丝刀装螺丝，用锤子装钉子.例如，不要期望将依赖于(Ab)使用local()或global()的Python代码原样带入C#.
"不利的一面"是，大多数静态类型语言(这里是C#)都需要显式编译优先(但这并不是很糟糕，因为它可以制作漂亮的程序集)，而且像"REPL"这样的工具不会被视为一等公民(它在F#/VS2010中是一等公民).此外，如果您有一个适用于Python/C#的必需库(并且不支持另一种语言)，这可能是为什么 Select 一种语言而不是另一种语言的决定性因素.