3 ms·
This might be the flak you're expecting, but when I see locals() used in production code I've had problems refactoring it. I don't see how it's different from "
by pfranz 5y ago
This might be the flak you're expecting, but when I see locals() used in production code I've had problems refactoring it. I don't see how it's different from "from foo import *" I appreciate the terseness but looking at the code, or even with the IDE's help, I can't really see what's expected (especially if I'm looking at someone else's code). If I move things around I'll get bit at runtime--perhaps in a corner case that doesn't get caught the first time you run it.
Maybe this is the use-case you're talking about, but when I have something super generic I usually have clear and careful error handling inside. It kind of defeats the terseness of using locals(), but the goal is more about flexibility.
- eesmith 5y agoHere's a locals() example from apsw: # You can use local variables as the dictionary title="..." isbn="...." cursor.execute(sql, locals()) In the pre-dataclass / pre-namedtuple days I would use: class Spam: def __init__(a=1, b=2, c=3, d="four", .. lots args ..): self.__dict__.update(locals()) del self.self in prototype code. But that wouldn't go into production. (I wouldn't put the namedtuple version in production either.)