Actually, variable names should largely /not/ be lost - Python is insanely dynamic and needs variable/function/etc. names to remain.
At most you might lose the names of local variables inside a function (i.e. variables that, due to internal scope, have a limited lifespan), but member variables, global variables, function names, class names, method names, etc. would all need to be kept in the bytecode.
Considering `globals` and `locals` exist I would be very surprised if any name got lost. Python is so dynamic you can actually mutate the bytecode of a function at runtime[0] (LISP esque), so the compiler can't actually make any assumptions and optimizations based on your source code.
Ah, that's unfortunate. I sort of assumed the compiler would be able to optimize stack variables and only do the slow thing if `locals` was actually invoked.
It's a common joke to say that if you just shorter names in C, your program might run faster. It's not true of course, but it Python, it might. All those names are used in hash computations and look ups, and you may shave a few micro seconds if you make your program unmaintable.
Actually, no, shortening names won't speed bytecode up in the way you seem to be suggesting. Variables "are" indexed by position in some arrays like co_varnames, co_names, co_const and so on. See for example https://docs.python.org/3.8/library/dis.html?highlight=co_na...
There are maps in the code object that will turn the index back into a name, but that's only used when some sort of introspection occurs, such as you might find in a debugger or traceback.
The names found in an "import" of course is a string so there might some small advantage there in a shorter name.
At most you might lose the names of local variables inside a function (i.e. variables that, due to internal scope, have a limited lifespan), but member variables, global variables, function names, class names, method names, etc. would all need to be kept in the bytecode.