什么事件顺序使Django成为最受欢迎的Python Web框架。即使存在其他几个框架。
注意：这个问题既非论争也不是对抗性的。我只是要求（客观）导致其实际流行的“事件顺序”。意识到软件接受的动态，我无意让任何人就技术优势争论不休。
什么事件顺序使Django成为最受欢迎的Python Web框架。即使存在其他几个框架。
注意：这个问题既非论争也不是对抗性的。我只是要求（客观）导致其实际流行的“事件顺序”。意识到软件接受的动态，我无意让任何人就技术优势争论不休。
Answers:
我认为有几个因素，这些因素的总和大于各自权重的总和。
一个简单的时间就是：随着Rails的第一波大肆宣传，Django的出现恰到好处，因此它立即被描绘成“ Python对Rails的回答”。几乎从一开始就在该项目上引起了不小的关注。Adrian参加了在芝加哥举行的“蛇与红宝石”聚会，并参加了有关Rails和Django的并排讨论，这一事实为此做出了很多贡献。
另一个因素是Django一直并且一直都是单软件包安装（嗯，还不完全是：您仍然需要一个数据库适配器，除非您使用的是Python 2.5+和SQLite，但足够接近）。非Zope替代方案都致力于将组件的选择权留在开发人员手中，为了使您可以进行基础教程，需要做大量工作：您需要深入研究ORM，模板语言等），并进行安装和配置。尽管这些年来情况已经好得多，但我认为对此的挥之不去的记忆仍然会产生影响。
Django提供的文档（如果我自己也这么说的话）远远超出了开源项目的通常标准，并且随着时间的推移才变得更好。本教程尽管有很多缺点，但在许多方面都达到了使Django有用的高点，并且本文档的其余部分始终保持良好的质量，并根据需要混合了API参考和重要的“操作方法”。这提供了良好的开箱即用的体验，并有助于教程后的学习曲线（这一直困扰着Zope）。
我还认为，不管是对还是错，都有一种看法，那就是，Pylons或Werkzeug对于那些已经了解WSGI和Python网络生态系统方式的经验丰富的开发人员确实更好。我认为，它们往往是选择您现有的最喜欢的库并将它们插入在一起的强大选择，这一事实的根源在于，也许这会促使一些新人转向Django的集成方法。当然，不利的一面是，许多在尝试使用Django之前最好先学习更多的人不要这样做；）
最后，我认为对于Django的销售方式来说，还有很多话要说，那就是它确实没有销售很长时间了，或者至少在某种意义上说不是，例如Rails的销售。在Django 1.0登陆之前，“市场营销”工作主要是由人们写博客（有些显着事件要求人们对其进行细化），在PyCon上进行讨论，然后主要只是改善框架，使用它来构建有趣的东西。让结果说明一切。当然，现在，在1.0版之后的世界中，我们有DSF和DjangoCon以及面向业务的顾问进行培训课程，大量书籍以及所有其他内容，但这仍然是相当新的。
我希望会出现反弹，就像Rails一样，实际上我认为它已经酝酿了一段时间并且已经开始。但是直到现在，我认为我在这里列出的因素至少是自从Django首次发布以来，人气持续稳定增长背后的主要因素。
当Django于2005年问世时，已经存在许多Python网络框架-的确，到那时，笑话已经传开了，Python是“网络框架比关键字多的语言”（而Guido拒绝了我的建议，即在Py3k中修复该问题，添加很多很多其他关键字）。现在，“ django”本身作为搜索词有点含糊（它也是一个流行吉他手的名字，他的生活启发了伍迪·艾伦电影等），但是在搜索中添加了“ python”以删除其他含义您可以在此图中看到例如与另一个经典的Python网络框架Zope相比，它的相对受欢迎程度发生了怎样的变化。通常每季度都保持稳定的增长，在2008年第二季度初出现了惊人的大幅增长……这恰好与Google宣布App Engine的日期一致（在这种情况下无法证明因果关系，但是巧合的是至少有趣；-)。
App Engine本质上排除了任何高度依赖自定义C编码组件或本质上需要“高度关系”功能的Python网络框架；在仅使用纯Python代码运行良好的代码中，Django可能是App Engine最直接，最明显地支持的代码。但是，这只是一个推动，增加了Django潜在的健康增长趋势。对于这种趋势的解释（实际上是对App Engine团队以及用户如此出色地支持Django的决定）的解释必须在于Django本身固有的特征。
与Pylons，TurboGears，Werkzeug和＆c等重量较轻的替代品相比，Django有时会因“过于魔术”或“过于单一”而受到批评（包括……您的真心地-）。 ，我最喜欢的;-)更加透明，并且允许更轻松地交换特定组件（ORM，模板和＆c）。但是，Django的受欢迎程度告诉我们，对于大多数对开发服务器端网站和应用程序感兴趣的人来说，这些Django设计选择得到了积极的评价：Django被视为一个非常丰富且集成良好的框架（它确实有很多附加功能，并贡献了“插件”，但这些更多的是结果而不是其优势。
易于上手，自动的“管理页面”之类的东西-以及Django可以通过大量的技巧和一些工作来弯曲制作真正丰富而复杂的网站/应用并适应特殊或独特的要求的事实-可能是“杀手级功能”。要最好地使用Werkzeug，您需要了解HTTP和WSGI，并选择和集成自己喜欢的存储和模板-基于Python的网站和应用程序的开发人员（从某种意义上说，例如Rails的用户或甚至更受欢迎的PHP！-）都在为自己的环境“投票”，在这种环境中，他们不一定需要做任何事情，而是可以专注于他们的应用程序领域。我不得不承认他们可能确实有一点；-)。
len(keyword.kwlist)-例如，typenames不是关键字在Python等
我注意到它经常被提升为Python上的Ruby on Rails等效项。它还与Google有连接（Google托管Django事件，并在其App Engine中支持它）。Google认可的Web框架必须物有所值。:)
至少对我来说，一个重要因素是Simon Willison和Adrian Holovaty以及后来的Jeff Croft在“ Web Standards”领域已经是知名的参与者。
这不仅是质量保证，而且还使Django非常易于使用，因为它尊重HTTP，标记，甚至习惯了PHP人士使用的快速，肮脏的“打印调试”工作方式。
我可能在这里很错，没有数据可以支持，但是我觉得Django从PHP的人那里获得了更多的吸引力，而Rails从Java / .NET进行了很多转换。
正如其他人已经指出的那样，文档远高于平均水平。据我所记得，这是我见过的最好的。