Python vs C#/.NET——使用 Python 开发大型 Web 应用程序需要考虑的主要区别是什么？

Python vs C#/.NET -- what are the key differences to consider for using one to develop a large web application?

提问by Zugwalt

My organization currently delivers a web application primarily based on a SQL Server 2005/2008 back end, a framework of Java models/controllers, and ColdFusion-based views. We have decided to transition to a newer framework and after internal explorations and mini projects have narrowed the choice down to between Python and C#/.NET.

我的组织目前提供主要基于 SQL Server 2005/2008 后端、Java 模型/控制器框架和基于 ColdFusion 的视图的 Web 应用程序。我们决定过渡到更新的框架，经过内部探索和小型项目，我们将选择范围缩小到 Python 和 C#/.NET 之间。

Let me start off by saying that I realize either technology will work great, and am looking for the key differentiators (and associated pros and cons)These languages have a lot in common, and a lot not--I'm looking for your take on their key differences.

首先让我说我意识到任何一种技术都可以很好地工作，并且正在寻找关键的区别（以及相关的优缺点）这些语言有很多共同点，但很多不是 - 我正在寻找你关于他们的主要区别。

Example tradeoff/differentiator I am looking for:

我正在寻找的示例权衡/差异化因素：

While it seems you can accomplish more with less code and be more creative with Python, since .NET is more structured it may be easier to take over understanding and modifying code somebody else wrote.

虽然看起来你可以用更少的代码完成更多的工作，并且使用 Python 更有创意，但由于 .NET 更加结构化，因此接管理解和修改其他人编写的代码可能更容易。

Some extra information that may be useful:

一些可能有用的额外信息：

Our engineering team is about 20 large and we work in small teams of 5-7 of which we rotate people in and out frequently. We work on code that somebody else wrote as much as we write new code.

我们的工程团队大约有 20 人，我们在 5-7 人的小团队中工作，其中我们经常轮换人员。我们处理别人编写的代码和我们编写新代码一样多。

With python we would go the Django route, and with .NET we would go with MVC2. Our servers are windows servers running IIS.

对于 Python，我们将采用 Django 路线，而对于 .NET，我们将采用 MVC2。我们的服务器是运行 IIS 的 Windows 服务器。

Some things we like about ColdFusion include that its very easy to work with queries and that we can "hot-deploy" fixes to our webservers without having to reboot them or interrupt anybody on them.

我们喜欢 ColdFusion 的一些方面包括它非常容易处理查询，并且我们可以“热部署”修复我们的网络服务器，而无需重新启动它们或中断任何人。

---

---

I've read some of the other X vs Y threads involving these two languages and found them very helpful, but would like to put Python head-to-head against .Net directly. Thanks in advance for letting me tap your experiences for this difficult question!

我已经阅读了一些涉及这两种语言的其他 X 与 Y 线程，发现它们非常有帮助，但我想直接将 Python 与 .Net 正面交锋。在此先感谢您让我利用您的经验解决这个难题！

采纳答案by Zugwalt

".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")

“.NET”不是一种语言。也许是 Python 与 C# 或 Python/Django 与 C#/ASP.NET（或选择您想要的任何“网络工作”；Python 和“.NET”有许多不同的解决方案，选择 Django 或 MVC2 的蝙蝠可能严重限制了更好的可行选择）。作为对 Python 与“.NET”的反击：有IronPython（Python“in .NET”）

I would consider: Developer comfortwith 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).

我会考虑：开发人员对一种语言的舒适度，如果它们在 Python 和“.NET”中相等，那么我会考虑开发周转时间并选择最小化这种语言/“网络工作”（同样，它不必是以前的）约束）。

While unit/integration-testing is a must for any [sizable] project, I find that a statically typed language(C#/F#) can greatly reducethe number of "stupid bugs" relating to types.

虽然单元/集成测试对于任何 [sizable] 项目都是必须的，但我发现静态类型语言(C#/F#) 可以大大减少与类型相关的“愚蠢错误”的数量。

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 hasand 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).

在这种情况下，C# 是一种非常无聊的命令式静态类型语言，具有基于单继承/接口类的 OO（但比 Java 有一些更巧妙的技巧，Java 只是彻头彻尾的石器时代）。这是与 Python 相同的基本面向对象类型，不包括静态/动态位，两种语言都是强类型的（机制不同，但最终结果在语言范围内非常相似）。实际上，python 有 MI，但在 python 中似乎不太被接受，因为它使用了 'lambda' 关键字，并且由于 python 是动态类型的，因此没有编译时支持确定接口/类型契约（但是，有一些模块可以尝试提供这个）。

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).

如果你可以学习/了解Python，那么你就可以学习/了解C#。这不是范式转变。这里有一些关键字，那里有大括号，需要说明你在那里指的是什么类型，不同的基础库......不同的环境（你必须争取一些才能获得 REPL，但它在 VS 中是可行的。）开发人员如何喜欢/学习/使用它是另一回事。虽然我之前确实将 C# 称为命令式，但很高兴看到添加了一些“类似函数”的特性，例如 LINQ/IEnumerable 扩展和没有委托的闭包，即使基本的 C# 语法非常程序化——再一次，很漂亮很像 python（for 表达式、嵌套函数、语句/表达式除法）。

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-timeand 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.

虽然新的“动态”确实模糊了界线（很少有很好的用途——在几乎所有相同的地方，人们可能不得不退回到以前的 C# 版本中的反射——这不是真的，但是关键是它通常是“错误的方式”，除了在少数情况下它恰好是“最好/唯一的方式”），“var”不是。也就是说，“VAR”变量的类型是在编译时已知的和无关与动态类型; 这都是类型推断。某些语言（如 F#/SML 和 Haskell）具有更强大的类型推断，无需“所有那些丑陋的类型声明”（尽管显式注释允许的类型或类型集可以使意图更加清晰），同时保留静态类型。

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.

就个人而言，除此之外，我会使用静态类型语言。我不是在说 C#（我绝对不是在说 Java！），但是静态类型的语言可以将类型错误推到最顶端，并且需要预先明确的约定（这对我来说是一个巨大的胜利）。虽然您确实错过了一些巧妙的动态技巧，但几乎总有一种更好的方法可以用目标语言执行相同的操作——您只需要考虑该语言，然后用螺丝刀拧螺丝，用锤子拧螺丝钉子。例如，不要期望将依赖于（ab）使用 local() 或 global() 的 Python 代码按原样引入 C#。

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.

在“不利方面”，大多数静态类型语言（此处为 C#）需要显式的编译优先（但这并没有那么糟糕，因为它可以生成漂亮的程序集）并且诸如“REPL”之类的工具不被视为第一-类公民（它是 F#/VS2010 中的一等公民）。此外，如果您有 Python/C# 的基本库（并且在其他语言中不可用），这可能是决定为什么选择一种语言而不是另一种语言的决定性因素。

回答by Alex Yakunin

I wrote a very comprehensive answer on Quora about this: How does Python compare to C#?

我在 Quora 上写了一个非常全面的答案：Python 与 C# 相比如何？

TL;DR

• The answer is huge, but (hopefully) quite comprehensive. I programmed on C# / .NET for almost 10 years, so I know it really well. And I program on Python at Quora for ~ 7 months now, so I hope I know it pretty well.

• Python is winner in: ease of learning, cross platform development, availability of open source libraries

• C# is winner in: standard library, language features, development process and tools, performance, language evolution speed
• Roughly even: syntax (Python is better in readability, C# has more consistent syntax), adoption.

TL; 博士

• 答案是巨大的，但（希望）相当全面。我在 C#/.NET 上编程将近 10 年，所以我非常了解它。我现在在 Quora 用 Python 编程了大约 7 个月，所以我希望我很了解它。

• Python 的优势在于：易于学习、跨平台开发、开源库的可用性

• C# 胜出：标准库、语言特性、开发过程和工具、性能、语言进化速度
• 大致均匀：语法（Python 的可读性更好，C# 的语法更一致）、采用。

回答by Faraz M. Khan

I would also suggest we must compare runtimes and not limit to language features before making such moves. Python runs via interpreter CPython where C# runs on CLR in their default implementations.

我还建议我们在进行此类操作之前必须比较运行时而不是限制语言功能。Python 通过解释器 CPython 运行，其中 C# 在其默认实现中的 CLR 上运行。

Multitasking is very important in any large scale project; .NET can easily handle this via threads... and also it can take benefits of worker processes in IIS (ASP.NET). CPython doesn't offer true threading capabilities because of GIL...a lock that every thread has to acquire before executing any code, for true multitasking you have to use multiple processes.

多任务处理在任何大型项目中都非常重要；.NET 可以通过线程轻松处理这个问题……而且它还可以利用 IIS (ASP.NET) 中的工作进程。由于 GIL，CPython 不提供真正的线程功能……每个线程在执行任何代码之前都必须获取的锁，对于真正的多任务处理，您必须使用多个进程。

When we host ASP.NET application on IIS on single worker process, ASP.NET can still take advantage of threading to serve multiple web requests simultaneously on different cores where CPython depends on multiple work processes to achieve parallel computing on different cores.

当我们在 IIS 上的单个工作进程上托管 ASP.NET 应用程序时，ASP.NET 仍然可以利用线程在不同的内核上同时处理多个 Web 请求，其中 CPython 依赖多个工作进程来实现不同内核上的并行计算。

All of this leads to a big question, how we are going to host Python/Django app on windows. We all know forking process on windows is much more costly than Linux. So ideally to host Python/Django app; best environment would be Linux rather than windows.

所有这些都引出了一个大问题，我们将如何在 Windows 上托管 Python/Django 应用程序。我们都知道 Windows 上的 fork 进程比 Linux 成本高得多。非常理想地托管 Python/Django 应用程序；最好的环境是 Linux 而不是 Windows。

If you choose Python, the right environment to developed and host Python would be Linux...and if you are like me coming from windows, choosing Python would introduce new learning curve of Linux as well...although is not very hard these days...

如果您选择 Python，那么开发和托管 Python 的合适环境将是 Linux……如果您像我一样来自 Windows，那么选择 Python 也会引入 Linux 的新学习曲线……尽管现在不是很困难...

回答by bjoern

The main problem in industry is the dynamic nature of python. Because you have some kind of safety with a static typed language.

工业界的主要问题是python的动态特性。因为您对静态类型语言具有某种安全性。

But now we have modern IDEs like PyCharm. They integrate pylint and pep8 "code-checking" and "styleguide-check" when you type in your code. That eliminates the most stupid errors. So you have almost have the same safety in python now.

但是现在我们有了像 PyCharm 这样的现代 IDE。当您输入代码时，它们集成了 pylint 和 pep8“代码检查”和“样式指南检查”。这消除了最愚蠢的错误。所以你现在在 python 中几乎拥有相同的安全性。

The other thing is, if you need "static type checking" do it by yourself when you need it. That's the pragmatic nature of python.

另一件事是，如果您需要“静态类型检查”，请在需要时自己进行。这就是python的务实本质。

The GIL is a problem, but you can use gevent or ZMQ to do a kind of threading. But work in progress on PyPy STM.

GIL 是一个问题，但是您可以使用 gevent 或 ZMQ 来进行一种线程处理。但 PyPy STM 的工作正在进行中。

Python runs almost everywhere and you have the choice of different, mostly compatible, runtimes (12 on Wikipedia) Wikipedia python interpreter list

Python 几乎可以在任何地方运行，您可以选择不同的、大多数兼容的运行时（维基百科上有 12 个） 维基百科 python 解释器列表