偶对django的rant

本文乃我半夜不爽的咆哮之作。django的忠实fans可无视本文。


久闻django大名，号称与ROR齐名。刚才就开始看hideto的《翻译www.djangobook.com系列》。然而一边看一边摇头，才看到第四章模板当中，我就看不下去了。

django的设计实在是太恶心了！

就我看的这几章已经暴露出的问题：

1. url要用正则匹配，这是很差的设计，完全罔顾url的最常见的匹配习惯就是按照 / 来划分的事实。诚然正则具有最大的灵活性，但是这种所谓灵活性在url匹配这个事例中完全是负担！仅就这一点设计而言，django就不配称快速开发框架。因为光光一个充斥^$好多括号的配置文件已经足够把人折腾死了。

2. 最简单的几个配置文件都要import。。。view里的request居然也要import。难道是python的限制？

3. 使用template要指定，难道没有默认约定吗？

3. 模板太奇怪。首先是{%，为什么不用<%？php,asp,jsp都用，django偏偏要独树一帜？那么独树一帜（比如velocity用#，比如xquery直接用 { } ），你干脆别用那可恶的%符号啊，{和%的组合莫名其妙不伦不类。

4. {%如果说纯粹是个人喜好问题，那么模板的功能限制就是实在的大问题。诚然，我赞同对模板加以限制的设计哲学。但是django的平衡点实在混乱。

只支持无参方法调用，但又加了silent_variable_failure和alters_data。事实是：方法是否可用于view，与有否参数无关（因为过滤器其实就是变相方法）。你要么就什么方法都不支持（像jsp一样），所以silent_variable_failure和alters_data这两个属性根本就是为了错误的设计决策打的patch！

不许if混用and / or，但是要求if嵌套？当模板作者都是白痴啊！

不许写 if a = b，偏要写ifequal a, b，我只能说设计者的脑子进水了！！

唯一值得庆幸的是，django总算允许使用其他的模板系统。（但是我疑惑有多少用户选择其他模板系统？）

关于django的模板哲学（引自hideto的译文）

“有些其它的模板语言是基于XML的
XML的格式容易输错，并且XML的模板解析速度也容易变得很慢而难以接受 ”

胡扯！xml格式容易输错吗？{%就不容易输错？！有无数的工具支持xml，无论ide或者简单的编辑器都支持xml。xml解析速度慢吗？完全胡说八道。

“Django模板系统没有设计成可以在Dreamweaver等WYSISYG编辑器中显示良好
这类编辑器有很多限制，Django希望模板作者直接编辑HTML时感到舒适 ”

虽然我也不喜欢WYSISYG编辑器，但是通过攻击WYSIWYG编辑器来给自己的设计不兼容此类编辑器找借口，我只能对设计者树中指！

“模板系统的作者意识到大部分Web页面的模板是页面设计者写的而不是Python程序员写的
他们不具备Python知识”

所以又要学一种新语言。而且这种语言又不像xml（因为xml容易输错解析慢），又不像asp/php/jsp（鬼知道什么原因），又不兼容wysiwyg编辑器（因为希望你直接编辑html时感到舒适！）……请问，这种模板是要给谁写的？python程序员？html程序员？js程序员？美工？没有一种人会喜欢它。特别是那些拼写equal也拼不清楚的人（操，我都要确认两遍是ifequal而不是ifequals，奶奶的，你就不会简写成ifeq吗？对了，还有一个狗屁的ifnotequal）

“模板不能设置和改变变量的值
可以通过自定义模板标签来达到这个目标，但是内置Django模板标签不允许这样做”

是的，我警告过你们了，改变值是邪恶的，其实你们最好回去用xslt模板，django模板只是xslt模板的拙劣的变形，为的是照顾你们这些被蛇般邪恶的py..——哦我是说c,java还有c#惯坏的可怜程序员们的智商。

另一方面，在给template传值的时候，倒可以使用locals()这样邪恶的函数。当然这是python的错，我相信要给django的设计者来选择，如果有可能的话，他一定不会让这么邪恶的事情发生！

……

原谅我用“恶心”两个字形容django，因为我没想到它是如此“独特”。如果不是标题是django，在阅读的时候我还以为这又是哪个山寨框架（参见JE最近热帖）呢！

我只是看了点文档就发觉了这些问题，其实这些问题django的用户不是没有感觉——因为我好奇如此拙劣的设计怎会没有人抱怨，所以我搜索了一下：


http://groups.google.com/group/python-cn/browse_thread/thread/c32a8ba1b2e1f5f3/56ad35cbc4dd21d9

一位django的曾经用户因为不堪忍受django而开始自制山寨框架 写道

至少从我个人角度来说，我是离django越来越远了，因为许多不满意的东西无法得到改善，只好另起炉灶了。许多东西django可以说做得还不错，但是仍然有 许多的问题，比如说：
社区的开放性。许多核心成员过分强调他们的哲学，造成他们无法听进去别人的意见，比如template的所谓简洁性就是一个例子。模板的简洁造成功能就有限制， 因此django的模板允许你使用tag。但这样一来造成tag本身就是另一种语言了，而且是由许许多多的人维护的语言。写一个tag我并不认为很轻松。与其如 此，不如直接引入python代码，象许多模板系统一样。用不用是用户的事，但有没有是框架的事。django小组对社区的建设也不尽人意。象ruby有仓库的 网站，不知道django现在有没有，这个问题也早就提过，但是至少从我不开始关注django的时候之前一直没有改善。这一点非常影响一个社区的发展。
过分看重admin功能，以至于把其它可以做得更好的地方给忽略了。比如ajax框架。再比如说自动模板对应，这在ruby,
web2py和uliweb中都有，可以非常简化。而django在做这个时候很简单，就是定义了一个render_to_response()，因此说dja ngo的复杂需要你记住许多的模块是如何被导入的，虽然有这些简化的方法，但仍然不够简单。再比如说urls.py，刚开始还是不错，但是后来发现，定义一个包 括了正则式的url还是挺麻烦的，远没有某些Route模块简单。
算了，不说了，各有所爱。
……
模板为什么会复杂，我认为更多是因为模板本身造成的。比如web2py的模板可以直接嵌入python代码，但是它的模板tag就那么几个，你认为它复杂吗？并 不是模板本向复杂，而是因为模板中的内容复杂。django模板的弱化，导致tag库盛行，但是tag写起来容易吗？它不也算是一个DSL的东西？与其如此还不 如直接使用python代码，至少我认为python代码比tag要简单多了。比如你做一个比较：
{% if var is None or a == b %}
不知道现在这个在django中是否可以支持，一个挺简单的比较，怎么就有好几个标签：if, ifequal,
ifnotequal。再去djangosnippets上看一看，为if做的扩展tag也有好多，我还写过一个pyif的tag，目的就是可以在django 模板中直接使用python表达式，这本来就是很简单的事，结果django给做复杂了。
……
举例来说：从一开始我就不喜欢那个DJANGO_SETTINGS_MODULE，真是麻烦死了，它甚至都不能有个缺省的判断。
http://code.djangoproject.com/ticket/824
在这个ticket我其实是想说当不存在时可以有一个缺省的判断。但是下面的回复却是告诉我在使用前应该设置一下。
http://code.djangoproject.com/ticket/904
在这个ticket下，有人给出一个缺省查找的补丁，但是被拒绝，应该是通过 django.conf.settings.configure()
来手工设定，还是很麻烦。
这只是一个例子。说明django在某些地方的独立性和智能化(或缺省设置)的处理上还不够。

可以看到，我刚才说的那几个问题他都提到了。我没提到的问题他也提到了（毕竟是受害者，我目前只是看客罢了）



我其实对于python社区的web框架抱有厚望，很多年以前zope就令我倾倒。可是等了那么多年，许多人推崇的django就是这么一个货色，实在令我大惑不解。也许是因为python社区以前没有足以与它竞争的框架。不过一般而言，如果不考虑平台（譬如GAE），那我前有ROR，后有Grails，怎么都不会选django这个货色。


附笑话一则：

引用

再举个例子，{#
#}和{%comment%}{%endcomment%}都是用来生成注释的，但是前者是不能有换行的，而后者可以任意。可以看出在django的模板中还区 分单行注释和多行注释。以前在邮件列表中就讨论过这件事，但是django团队不同意修改。好象理由就是象c/c++之类的语言有就单行与多行的区别，并且不一 样。麻烦不，用{##}多简单啊。为什么强调不引入过多的程序逻辑，但是到了注释却搞出个单行和多行。所谓的前端开发者谁管别的语言是怎么定义的，django 怎么定义就怎么用呗，这里真是没有必要。只是注释而已，也没有什么特殊的处理原因，还搞出那么多的tag。

评论

35 楼 panboxian_2008 2010-01-23  

要用rails肯定有一个接受的过程，就像起初 用django一样！

34 楼 panboxian_2008 2010-01-23  

rails没有深入，django倒用了点，现在要接受rails也挺别扭的！但我相信rails肯定很好！

33 楼 范三山 2010-01-14  

把模板替换成mako
自己写个url规约，自动寻找方法和模板，弄成rails那样。
我觉得已经非常好用了

32 楼 ak47none 2010-01-13  

模板对应着MVC中的View，重心在于如何显示数据，而不是显示什么数据，因此if之类的逻辑判断应该尽量少用。说到底，还是设计思路的差异。

31 楼 cgwangjun 2009-05-06  

起初读了楼主的感观，差点与Django失之交臂，后来发现，中小项目，django还是比Zope要来得直观好维护一些。

除了django，大家还拿什么构架与 Python 配呢？

30 楼 tinsn 2009-05-06  

lw223 写道

jejwe 写道

楼主提到的“一位django的曾经用户因为不堪忍受django而开始自制山寨框架”，不就是国内PYTHON界的大牛LIMODOU，好像他从来也没有"不堪忍受"，只不过他有更多的自己的想法，而且有能力自己去做一个框架。建议楼主不仿看看limodou的uliweb
http://www.17xie.com/book-32498995.html

ls你给的什么网站？ 有病毒。我的用的avast杀毒软件。

django用来做中小网站还是很方便的，做其他的就不行了。

是一个写书的网站，limodou的leaning uliweb 可以在这里看到。
这里是他的老窝

29 楼 hax 2009-05-03  

你用两年时间学会容忍django的坏味道（久闻……不觉其臭），到头来还不是无法忍受django的模板？django之“道”是一体的，如果你换了模板系统，还是内嵌python，只能说明你嘴上体会了，实际上没体会django之“道”。

当然，很明显，我对django之“道”是嗤之以鼻的。虽然我始终认为人生不可预期，不过负责的说，再有两年、三年、五年，我也不会“领会”django之“道”。

28 楼 towjzhou 2009-05-03  

很明显，楼主还没有领会django之道，我以前刚用django时也写了个喷django的贴子，不过，二年之后，我已经体会了为什么django会设计成这样了。

不过，它的模板确实不是很完美，所以，我自已做了一个模板系统，语法和django的差不多，不过是内嵌python代码，而且不用考虑缩进。

27 楼 剑事 2009-05-01  

有python ide就够了 django倒不需要

form可以再优化些， 不过可定制性不错，用深了才能体会

ORM 有些地方比 sqlalchmey 好点
整体还是sqlalchmey 强的多

有些人疑问为什么django不用sqlalchemy,sqlobject非要自己开发
我觉得可能是FORM和ORM model整合的原因

26 楼 yyliuliang 2009-04-30  

第一点，url匹配使用正则明明是优点怎么就成了恶心呢 

25 楼 下一站，火星 2009-04-30  

mubs 写道

感同身受。我用django做过两个项目，一个网站，一个应用系统，做网站还算方便，做应用系统苦不堪言。如果说URL正则匹配还能忍受的话，那么那个form是我最不能忍受的东西，这明明就是struts里的form啊，照我看来django就是一个python版的struts。

这位同学说的很对！

1 form也是我最不能忍受的东西！简单的东西复杂化。
2 缩进我也不大喜欢，是一门伤人眼睛的语言！
3 缺乏一个好的IED支持！
4 恶心的下划线！
5 django的发展太乱，路线不明确
6 django的team相对才华不够，rails team确实可以甩它几条街，新版本的rails一些特性让你想都不敢想！
7 E文不好的同学看都不要看
8 用这个的公司少，想招一个人也难
9 ORM做的绝对比模板还恶心
还是老老实实的ROR或者grails吧

24 楼 jindw 2009-04-20  

呵呵，吧django的模板换掉，用Lite XML吧
现在Lite4Python模板已经可以通过GoogleAppEngine自动编译了。

只是目前表达式支持还有些bug。也应该很快就会修复了。

23 楼 lw223 2009-04-12  

jejwe 写道

楼主提到的“一位django的曾经用户因为不堪忍受django而开始自制山寨框架”，不就是国内PYTHON界的大牛LIMODOU，好像他从来也没有"不堪忍受"，只不过他有更多的自己的想法，而且有能力自己去做一个框架。建议楼主不仿看看limodou的uliweb
http://www.17xie.com/book-32498995.html

ls你给的什么网站？ 有病毒。我的用的avast杀毒软件。

django用来做中小网站还是很方便的，做其他的就不行了。

22 楼 hax 2009-04-08  

jejwe 写道

楼主提到的“一位django的曾经用户因为不堪忍受django而开始自制山寨框架”，不就是国内PYTHON界的大牛LIMODOU，好像他从来也没有"不堪忍受"，只不过他有更多的自己的想法，而且有能力自己去做一个框架。建议楼主不仿看看limodou的uliweb
http://www.17xie.com/book-32498995.html

偶知呀。他没说不堪忍受，但他的行动就已经证明了。BTW，我的笑话也是从他那里批发来的。

21 楼 bohemia 2009-04-08  

xiaopaozi 写道

引用

所以我的理解，不是django设计哲学的问题，实在是python缩进带来的限制，其实你观察一下，没有一个python web框架是直接拿python代码做模板语言的。

python的缩进确实容易出问题，有时候写代码看着明明是对齐了，可是运行的时候就是出错。如果嵌套的层次稍多一点，自己就已经先蒙了，不知道现在在哪一层。还有，在perl里，你可以把多条命令写在一行，发送到远程主机上执行，python肯定是不行了。
各位大牛，Perl有没有像Django这样的WEB框架？如果有真的要好好研究一下。

俺从一开始就遵从Py的三从四德了.
不论是UE,还是VI, 一律用4个空格,替换TAB, 永远撇弃了TAB的噩梦.

20 楼 jejwe 2009-04-08  

楼主提到的“一位django的曾经用户因为不堪忍受django而开始自制山寨框架”，不就是国内PYTHON界的大牛LIMODOU，好像他从来也没有"不堪忍受"，只不过他有更多的自己的想法，而且有能力自己去做一个框架。建议楼主不仿看看limodou的uliweb
http://www.17xie.com/book-32498995.html

19 楼 xiaopaozi 2009-04-08  

引用

所以我的理解，不是django设计哲学的问题，实在是python缩进带来的限制，其实你观察一下，没有一个python web框架是直接拿python代码做模板语言的。

python的缩进确实容易出问题，有时候写代码看着明明是对齐了，可是运行的时候就是出错。如果嵌套的层次稍多一点，自己就已经先蒙了，不知道现在在哪一层。还有，在perl里，你可以把多条命令写在一行，发送到远程主机上执行，python肯定是不行了。
各位大牛，Perl有没有像Django这样的WEB框架？如果有真的要好好研究一下。

18 楼 xiaopaozi 2009-04-08  

引用

一开始研究django，看过pylons后马上放弃了django。如以上朋友所说的，django做他擅长的开发类型比如新闻网站很方便，但是做其它系统特别是应用系统则太不灵活了。

以前听过一个对比：django想引导你去构建它擅长构建的东西；而pylons可作为你构建任何应用背后的基石。

个人认为Django做中小网站是相当的快，确实不适合做应用，做企业应用java还是王道。

17 楼 dualface 2009-04-08  

呵呵，做网站嘛，还是 php 来得方便

16 楼 mingliangfeng 2009-04-08  

一开始研究django，看过pylons后马上放弃了django。如以上朋友所说的，django做他擅长的开发类型比如新闻网站很方便，但是做其它系统特别是应用系统则太不灵活了。

以前听过一个对比：django想引导你去构建它擅长构建的东西；而pylons可作为你构建任何应用背后的基石。