On Tuesday, March 19, 2019 at 3:48:27 PM UTC-5, Chris Angelico wrote: > > I can see in vartest() that it's using a LOAD_GLOBAL for that, yet first() > > and second() don't go searching upstairs for a meow variable. What is the > > basis behind this? > > > > Both first() and second() assign to the name "meow", so the name is > considered local to each of them. In vartest(), the name isn't > assigned, so it looks for an outer scope.
Thanks for the responses. I wanted to poke on this part just a little bit more. I want to mimic the proper behavior without having to go back to it repeatedly. Let's say I'm parsing this code and generating the byte code for it. I run into meow on the right side of an expression but never the left. At this point, do I always generate a LOAD_GLOBAL opcode? Is that done whether or not I know if the variable is defined in a higher scope? That's what it looks like from renaming it to something I didn't define. I just want to double check. On the interpreter side seeing the opcode, does that generally mean I walk up the variables I have in higher frames until I either run out of them or find it? Does that mean defining "global meow" basically states "always use LOAD/STORE_GLOBAL opcodes for this one, even if it shows up on the left side of an assignment first?" -- https://mail.python.org/mailman/listinfo/python-list
