我不喜欢重复——我认为“DRY”(不要重复自己)是关键的编程原则。因此,在类似的情况下,我确实使用了
locals()
。Django模板渲染远非这种情况的唯一情况:一般情况是“接受字典的函数或运算符,但不介意字典包含额外条目”。(例如,Python中的普通字符串格式化就是另一个这样的情况)。
然而,有一个相反的原则:程序应该以尽可能本地化的方式可理解——这有助于维护和重构(因为它消除了研究其他文件以检查哪些重构是可接受的需要)。这表明,在
locals()
的情况下,如果模板(或字符串格式等)是本地文字(罕见的情况,只使用了少量变量,因此
locals()
并没有太大的优势!-),那么这是可以接受的,但在模板位于不同文件的正常情况下会出现问题。
因此,在大多数情况下,使用
locals()
会严重阻碍重构。在Python的几乎所有情况下,局部变量及其名称可以自由更改作为局部重构的一部分,因为它们没有“外部可见”的影响......但是使用
locals()
会打破这一点——突然之间,您不能安全地将变量重命名为提供更好的清晰度的不同名称,以一种消除变量需要的方式重构代码流程等等,而不必每次都研究单独的模板文件以检查旧名称是否可能不需要(并且可能编辑模板文件,这可能是非常棘手的,例如如果它用于多种不同的自然语言进行i18n / L10n)。
因此,在除了性能的次要问题之外,有强烈的压力
不要在“严肃的”,“生产”代码中使用
locals()
——需要长期维护,因此易于重构和本地化。因此,当我“尽我所能进行编程”而不是“走捷径”时,我知道我最好避免使用
locals()
。
你想在模板呈现的上下文中拥有的值不一定作为本地裸名自然可用;也许其中一些或许大多数是计算结果、列表或字典中的项等。在这种情况下,如果只是将这些值累积到适当的字典中而不是分配本地裸名,那么避免使用
locals()
的诱惑就更容易了。
这并不是一个容易权衡的问题,因为两个好原则(避免重复和具有良好的局部性)不可避免地会发生冲突 - 因此,很好的问题!这不是一个完全可以用明确的黑白答案解决的问题,这就是为什么我试图从两个方面进行扩展的原因。最终,我认为这是一种“风格”方面的问题,编程团队可能会被建议采用团队统一的风格指南并坚持下去 - 至少它消除了每次出现这个问题时需要反复做出决定的需要,并产生更加同质化(从而易于维护)的代码库。[[我必须承认,在我所在的团队的样式指南中,尽管有许多其他指南,但从未明确提到过这个特定点!-)]]