".NET" is not a language. Perhaps it's Python vs. C# or Python/Django vs C#/ASP.NET (or pick whatever "webwork" you want; there are many, many different solutions for both Python and ".NET" and picking Django or MVC2 of the bat might severely limiting better viable options). As a counter to the Python vs. ".NET": There is IronPython (Python "in .NET")
I would consider: Developer comfort with a language and, if they are equal in Python and ".NET", then I would consider turnaround times for development and choose the language/"webwork" that minimized this (again, it need not be previous constraints).
While unit/integration-testing is a must for any [sizable] project, I find that a statically typed language (C#/F#) can greatly reduce the number of "stupid bugs" relating to types.
Open up the playing field :-)
Edit for comment:
Then you're just comparing languages.
In which case, C# is a very boring imperative statically typed language with Single-Inheritance/Interface Class-Based OO (but a few more neat tricks than Java, which is just downright stone-age). This is the same basic type of OO as Python has and excluding the static/dynamic bit, both languages are strongly typed (the mechanics are different, but the end result is quite similar in the language spectrum). Actually, python has MI, but that seems less accepted in python as the use of the 'lambda' keyword and since python is dynamically typed there is no compile-time support for determining interface/type contracts (there are, however, some modules that try to provide this).
If you can learn/know Python, then you can learn/known C#. It's not a paradigm shift. Some keywords here, braces there, need to say what type you mean there, a different base library... different environment (you have to fight some to get to a REPL, but it's doable in VS.) How developers like/learn/use it is another story. While I did call C# imperative before, it's nice to see the addition of some "functional-like" features such as LINQ/IEnumerable extensions and closures-without-delegates, even if the basic C# syntax is very procedural -- once again, pretty much like python (for-expressions, nested functions, statement/expression divide).
While the new 'dynamic' does blur the line (there is very rarely a good use for it -- in about all the same places one might have had to fall back to reflection in prior C# versions -- this isn't true, but the point is it's generally "the wrong way", except in the few cases when it just happens to be "the best/only way"), 'var' does not. That is, the type of a 'var' variable is known at compile-time and has nothing to do with dynamic typing; it is all type inference. Some language like F#/SML and Haskell have much, much more powerful type inference removing the need for "all those ugly type declarations" (although explicitly annotating allowed types or set of types can make intent more clear) while preserving static typing.
Personally, everything else aside, I would use a statically typed language. I'm not saying C# (and I'm definitely not saying Java!), but statically typed languages can push type errors to the top and require up-front explicit contracts (this is a big, big win for me). While you do miss out on some neat dynamic tricks, there is almost always a better way to perform the same action in the target language -- you just have to think in terms of that language and use a screwdriver for a screw and a hammer for a nail. E.g. don't expect to bring Python code relying on the (ab)use of local() or global() into C# as-is.
On the "down-side", most statically typed languages (C# here) require an explicit compile-first (but this isn't so bad as it makes pretty assemblies) and tools like the "REPL" aren't taken as first-class citizens (it is a first-class citizen in F#/VS2010). Also, if you have an essential library for Python/C# (and it isn't available in the other language), that may be a deciding factor as to why to choose one language over the other.