将实例变量重赋值为方法局部变量：是否合规、作用及性能影响？

Great question—this is a pattern you’ll spot in Python code from time to time, and it’s worth breaking down why it exists, whether it’s a good idea, and what impact it has.

What’s the Purpose of This Pattern? #

There are a few common reasons developers write code like this:

• Readability & Conciseness: If you’re using self.obj_foo or self.obj_bar multiple times in the method, assigning them to local variables cuts down on repetitive self. boilerplate. Your code gets cleaner and faster to scan—instead of parsing self. every time, you just see the variable name directly.
  For example, compare:

  def call(self):
      self.obj_foo.do_something()
      self.obj_foo.do_another_thing()
      self.obj_foo.final_step()
      self.obj_bar.do_something_else()
      self.obj_bar.cleanup()
  

  To:

  def call(self):
      obj_foo = self.obj_foo
      obj_bar = self.obj_bar
      obj_foo.do_something()
      obj_foo.do_another_thing()
      obj_foo.final_step()
      obj_bar.do_something_else()
      obj_bar.cleanup()
  

  The second version feels far less cluttered, especially with longer, more descriptive variable names.

• Historical Performance Optimizations: Back in older Python versions (pre-3.0), accessing local variables was significantly faster than looking up instance attributes. Local variables live in the function’s stack frame, while instance attributes require a lookup in the object’s __dict__ (or via the class hierarchy for inherited attributes). While modern Python interpreters (like CPython 3.8+) have optimized attribute access a lot, this habit stuck around—even though the performance gap is now negligible for most use cases.

• Avoiding Accidental Instance Modification: If you only need to read the value of the instance variable (not modify it), assigning to a local variable can prevent accidental overwrites of the instance attribute. For example, if you later write obj_foo = some_new_value, it only changes the local variable, not self.obj_foo. Note that this doesn’t protect mutable objects (like lists or dicts)—if you modify obj_foo.some_attribute, that will still affect the instance’s underlying object.

Is This a Bad Practice? #

It depends on the context:

• Redundant for Single Uses: If you only reference self.obj_foo once in the method, assigning it to a local variable adds unnecessary code. It’s better to just use self.obj_foo directly in that case.
• Potential for Stale Values: If your code runs in a multi-threaded environment, or if other parts of the program might modify self.obj_foo while the call method is running, the local variable will hold a stale reference. This can lead to bugs if you expect the latest value of the instance attribute.
• No Major Red Flags: In most single-threaded, straightforward cases, this pattern is harmless—and even beneficial for readability when variables are used multiple times. It’s not considered a "bad practice" by most Python style guides (like PEP 8), as long as it’s used judiciously.

Does It Affect Performance? #

As mentioned earlier, the performance difference is minimal in modern Python. Let’s put it in perspective:

• A local variable access is a single bytecode operation (LOAD_FAST), while an instance attribute access is two operations (LOAD_FAST for self, then LOAD_ATTR for the attribute).
• But unless you’re running this code in a tight loop that executes millions of times, you’ll never notice the difference. For most applications, readability should take priority over this tiny performance gain.

In short: This pattern is mostly about readability (with a historical performance angle), it’s not a bad practice when used appropriately, and performance impacts are negligible for most use cases.

内容的提问来源于stack exchange，提问作者sccrthlt