Django模板和当地技巧 [英] Django template and the locals trick
问题描述
django书籍提供了本地的技巧，以避免键入长列表的参数作为上下文词典 http://www.djangobook.com/en/2.0/chapter04/
它推荐这个懒惰的程序员，但指出一些开销，可能对性能有影响。
我想知道你们中有人是否在实际应用中使用本地化技巧。你推荐它还是坏习惯？
我不喜欢重复 - 我觉得干 不要重复自己，是一个关键的编程原理。因此，在类似的情况下，我确实使用了 localals（）。 Django模板渲染远不是这种唯一的情况：一般情况是一个函数或操作符接受dict，但不介意如果dict包含额外的条目。 （例如，Python中的普通字符串格式是另一种情况）。
但是，有一个反补贴原则：程序应该是可以理解的，这有助于维护和重构（因为它不需要研究其他文件来检查什么重构是可以接受的）。这表明，对于 locals（） case，如果模板（或字符串格式等）是本地文字（很少有一些变量可能是被使用，因此 localals（）不是一个巨大的胜利！），但在正常情况下，模板存在于不同的文件中是有问题的。
所以，在大多数情况下，使用 localals（）严重妨碍重构。在Python的几乎每一种情况下，局部变量和名称都可以随意地被重新改变，因为它们没有外部可见的效果，而是使用 locals（）断开 - 突然之间你不能安全地将一个变量重命名为一个不同的名称，提供更好的清晰度，重构代码流以不需要变量等的方式，而不用每次学习一个单独的模板文件，以检查旧名称是否可能不需要（并且可能会编辑模板文件，这可能是不平凡的，例如，如果它以多种不同的自然语言维护i18n / L10n）。
localals（）存在强大的压力>严重，生产代码，需要长期维护，因此易于重构和本地化。所以，当我编程最好我知道如何，而不是切角，我知道我最好避免 locals（）。 在渲染模板的上下文中要具有的值不一定是自然可用作本地裸名;也许其中一些或许多是计算结果，列表或词典中的项目等。在这种情况下，如果您只是将这些值累加到一个合适的字典中，而不是将它们分配给本地的裸名字，那么使用 locals（）的切角的诱惑更容易避免
这不是最简单的权衡，因为两个好的原则（避免重复，拥有良好的地理位置）是不可避免的冲突 - 因此是一个很好的问题！而不是一个完全容易受到黑色或白色黑色答案的影响，所以我试图在双方扩张。最后，我认为这是风格的一个方面，编程团队可能会建议采用团结一致的风格指导方针，并坚持下去 - 至少它不需要一遍又一遍的做出决定时间问题出现，并产生更均匀的（由此可维护的）代码库。 [[我必须承认，尽管许多其他人都有这个团队的风格指导方针，这个具体点从来没有被明确地解决 - ）]]]
The django books gives the local trick in order to avoid to type a long list of parameters as context dictionnary http://www.djangobook.com/en/2.0/chapter04/
It recommends this to lazy programmers but points out some overhead which may have an impact on performance.
I would like to know if some of you are using the locals trick on real applications. Do you recommend it or is it a bad practice?
I don't like repetition -- I think "DRY", "Don't Repeat Yourself", is a key programming principle. As a consequence, I have indeed used locals() in similar situations. Django template rendering is far from the only situation of this kind: the general case is "a function or operator which accepts a dict, but doesn't mind if the dict contains extra entries". (For example, ordinary string formatting in Python is another such case).
However, there's a countervailing principle: programs should be understandable in as localized a way as feasible -- that helps maintenance and refactoring (as it obviates the need to study other files to check what refactorings are acceptable). This suggests, for the locals() case, that it's OK if the template (or string format, etc) is a local literal (a rare case where only few variables are probably being used and thus locals() is not a huge win!-), but problematic in the normal case where the template lives in a different file.
So, using locals(), in most cases, seriously hampers refactoring. In almost every situation in Python, local variables and their names can freely be changed as part of a local refactoring, since they have no "externally visible" effect... but using locals() breaks that -- suddenly you can't safely rename a variable to a different name offering better clarity, refactor code flow in a manner that removes the need for a variable, etc, etc, without each and every time studying a separate template file to check if the old name might not be needed (and possibly editing the template file, which can be non-trivial, for example if it's maintained in several different natural languages for i18n/L10n purposes).
As a consequence, in addition to the secondary issue of performance, there is strong pressure against using locals() in "serious", "production" code -- code that does need long term maintenance and therefore easy refactoring and locality. So, when I'm "programming as best I know how", rather than "cutting corners", I'm aware I had better avoid locals().
The values that you want to have in the context in which the template is rendered are not necessarily "naturally" available as local bare-names, after all; maybe some or many of them are results of computations, items from lists or dictionaries, and the like. In this case, the temptation to "cut corners" with locals() is easier to avoid if you just accumulate those values into a suitable dictionary rather than assigning them local bare-names.
It's not the easiest tradeoff, because two good principles (avoiding repetition, and having good locality) are inevitably clashing -- therefore, good question! And not one entirely susceptible to sharp black or white answers, which is why I've tried to expand on both sides. In the end, I think it's one of those "style" aspects where a programming team might be well advised to adopt a team-uniform style guideline and stick to it -- at least it removes the need to make a decision over and over every time the issue arises, and produces a more homogeneous (and thereby maintainable) code base. [[I have to confess that this specific point has never been explicitly addressed in the style guidelines of teams I've been in, though, although many others have!-)]]
这篇关于Django模板和当地技巧的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
