python严格模块

重点 (Top highlight)

Welcome to the third post in our series on Python at scale at Instagram! As we mentioned in the first post in the series, Instagram Server is a several-million-line Python monolith, and it moves quickly: hundreds of commits each day, deployed to production every few minutes.

欢迎来到Instagram上有关Python的系列文章中的第三篇！ 正如我们在该系列的第一篇文章中提到的那样，Instagram服务器是数百万行的Python整体，并且移动Swift：每天数百次提交，每隔几分钟部署到生产中。

We’ve run into a few pain points working with Python at that scale and speed. This article takes a look at a few that we imagine might impact others as well. Consider this innocuous-looking sample module:

以这种规模和速度使用Python时，我们遇到了一些痛点。 本文介绍了一些我们认为可能也会影响其他方面的内容。 考虑以下无害的示例模块：

import refrom mywebframework import db, routeVALID_NAME_RE = re.compile("^[a-zA-Z0-9]+$")@route('/')
def home():
    return "Hello World!"class Person(db.Model):
    name: str

When someone imports this module, what code will run?

当有人导入此模块时，将运行什么代码？

• We’ll run a bunch of regex code to compile that string to a pattern object.
  我们将运行一堆正则表达式代码，以将该字符串编译为模式对象。

• We’ll run the @route decorator. Based on what we see here, we can assume that it's probably registering this view in some url mapping. This means that just by importing this module, we're mutating global state somewhere else.

  我们将运行@route装饰器。 根据我们在这里看到的内容，我们可以假设它可能是在某些url映射中注册此视图。 这意味着仅通过导入此模块，我们就可以在其他地方改变全局状态。

• We’re going to run all the code inside the body of the Person class, which can include arbitrary code. And the Model base class might have a meta-class or an __init_subclass__ method, which is still more arbitrary code we might be running at import.

  我们将在Person类的主体内运行所有代码，其中可以包括任意代码。 而且Model基类可能有一个元类或__init_subclass__方法，这仍然是我们在导入时可能正在运行的任意代码。

痛苦一：启动和重新加载缓慢 (Pain area one: slow startup and reload)

The only line of code in this module that (probably) doesn’t run on import is return "Hello World!", but we can't even say that for sure! So by just importing this simple eight line module (not even doing anything with it yet!), we are probably running hundreds, if not thousands of lines of Python code, not to mention modifying a global URL mapping somewhere else in our program. So what? This is part of what it means for Python to be a dynamic, interpreted language. This lets us do all kinds of useful meta-programming. What's wrong with that? Nothing is wrong with it, when you're working with relatively small codebases and teams, and you can guarantee some level of discipline in how you use these features. But some aspects of this dynamism can become a concern when you have millions of lines of code worked on by hundreds of developers, many of whom are new to Python. For example, one of the great things about Python is how fast you can iterate with it: make a change and see the result, no compile needed! But with a few million lines of code (and a messy dependency graph), that advantage starts to turn sour. Our server startup takes over 20s, and sometimes regresses to more like a minute if we aren't paying attention to keeping it optimized. That means 20-60 seconds between a developer making a change and being able to see the results of that change in their browser, or even in a unit test. This, unfortunately, is the perfect amount of time to get distracted by something shiny and forget what you were doing. Most of that time is spent literally just importing modules, creating function and class objects. In some ways, that's no different from waiting for another language to compile. But typically compilation can be incremental: you can just recompile the stuff you changed and things that directly depend