Django模板和locals技巧

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

我不喜欢重复--我认为“干”，“不要重复自己”，是一个关键的编程原则。因此，我确实在类似的情况下使用过locals()。Django模板渲染远不是这种情况的唯一情况:通常的情况是“一个接受dict的函数或操作符，但不介意dict是否包含额外的条目”。(例如，Python中的普通字符串格式化是另一种情况)。

然而，有一个平衡原则:程序应该以尽可能本地化的方式被理解--这有助于维护和重构(因为它避免了研究其他文件来检查哪些重构是可接受的)。这表明，对于locals()来说，如果模板(或字符串格式等)是本地文字(这是一种罕见的情况，因为可能只使用了很少的变量，因此locals()不是一个巨大的胜利！-)，那么它是可以接受的，但在正常情况下，如果模板位于不同的文件中，就会出现问题。

因此，在大多数情况下，使用locals()会严重阻碍重构。在Python中的几乎所有情况下，局部变量及其名称都可以作为局部重构的一部分自由更改，因为它们没有“外部可见”效果……但是使用locals()打破了这一点--突然之间，您不能安全地将变量重命名为不同的名称，从而提供更好的清晰度，以某种方式重构代码流以消除对变量的需要，等等，而不是每次都要研究单独的模板文件以检查是否不需要旧名称(并可能编辑模板文件，这可能不是微不足道的，例如，如果它是以几种不同的自然语言维护的，用于i18n/L10n目的)。

因此，除了性能的次要问题之外，在“严肃的”、“生产的”代码中使用locals()的压力也很大--这些代码确实需要长期维护，因此很容易重构和局部性。所以，当我“尽我所知去编程”，而不是“偷工减料”时，我意识到我最好避免使用locals()。

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

这不是最简单的权衡，因为两个好的原则(避免重复和具有良好的局部性)不可避免地会发生冲突--因此，好问题！而且不是完全容易受到尖锐的非黑或白答案的影响，这就是为什么我试图在两边都进行扩展。最后，我认为这是那些“风格”方面中的一个方面，建议编程团队采用团队统一的风格指导方针并坚持下去--至少它消除了每次出现问题时反复做出决定的需要，并产生更同构的(从而可维护的)代码库。[我必须承认，这一点在我所在团队的风格指南中从未明确解决过，尽管其他许多团队都有！-)]

Answer 2

我经常想做以下事情，但我不确定这是否真的有帮助。

class MyStruct(object):
     pass

def my_view(request, id):
    c = MyStruct()
    c.customer = ..
    c.invoice = ..
    c.date = ..
    return render_to_response('xxx,html',c.__dict__)

Answer 3

我个人不喜欢这样。除了一句古老的Python格言“显式比隐式好”之外，我可能没有理由偏爱它。我想确切地知道我的模板中包含了什么。