Django模板和本地人技巧

Question

django书籍提供了本地技巧，以避免将一长串参数作为上下文字典输入

http://www.djangobook.com/en/2.0/chapter04/

例：

def current_datetime(request):
    dt_now = datetime.datetime.now()
    return render_to_response('current.html', {'dt_now': dt_now})

变成：

def current_datetime(request):
    dt_now = datetime.datetime.now()
    return render_to_response('current.html', locals())

它推荐给懒惰的程序员，但指出一些开销可能会影响性能。

我想知道你们中的某些人是否在实际应用程序上使用了本地技巧。您推荐它还是不好的做法？

Answer 1

我不喜欢重复-我认为“
DRY”，“不要重复自己”是关键的编程原则。结果，我确实locals()在类似情况下使用过。Django模板渲染远非仅有这种情况：一般情况是“接受字典的函数或运算符，但不介意字典是否包含额外的条目”。（例如，Python中的普通字符串格式就是这种情况）。

但是，有一个相反的原则：程序应该以可行的本地化方式进行理解-
有助于维护和重构（因为它消除了研究其他文件以检查可接受的重构的需要）。对于这种locals()情况，这表明，如果模板（或字符串格式等）是本地文字（在极少数情况下，可能仅使用少量变量，因此locals()不是一个大赢家！），这是可以的，但在模板存放在其他文件中的正常情况。

因此，locals()在大多数情况下，使用会严重妨碍重构。在Python的几乎每种情况下，局部变量及其名称都可以在局部重构中自由更改，因为它们没有“外部可见”的作用…但是使用locals()中断，突然间，您无法安全地重命名变量到另一个名称以提供更好的清晰度，从而以无需变量等的方式重构代码流，而无需每次都研究单独的模板文件来检查是否不需要旧名称（并可能进行编辑）模板文件，这可以是很简单的，例如，如果出于i18n
/ L10n的目的以几种不同的自然语言对其进行了维护，则该模板文件是不重要的）。

结果，除了性能的次要问题外，还有很大的压力 要求 使用locals()“严肃的”，“生产”代码-
这些代码确实需要长期维护，因此易于重构和本地化。因此，当我“尽我所能编程”而不是“偷工减料”时，我知道我最好避免locals()。

毕竟，在呈现模板的上下文中要具有的值不一定是“自然”可用的本地裸名；也许其中一些或许多是计算的结果，列表或字典中的项等等。在这种情况下，locals()如果只是将这些值累加到合适的字典中而不是为其分配本地裸名，就更容易避免“偷工减料”的诱惑。

这不是最简单的权衡，因为两个好的原则（避免重复，并且具有良好的局部性）不可避免地发生冲突-
因此，这是一个好问题！而且没有一个人完全容易受到尖锐的黑白答案的影响，这就是为什么我试图在两侧都扩大。最后，我认为这是编程团队最好建议采用团队统一的样式准则并坚持下去的那些“样式”方面之一-
至少它消除了在每一个步骤中都要反复做决定的需要出现问题时，会产生更均一（从而可维护）的代码库。[[我不得不承认，尽管我所参加的团队的风格准则中从未明确提及过这一点，尽管许多其他团队都曾提到过！-]]