[Python-Dev] serious bug in new import X as Y code (original) (raw)

Sjoerd Mullender sjoerd.mullender@oratrix.com
Sun, 20 Aug 2000 16:54:43 +0200

This seems to have done the trick. Thanks.

Thomas Wouters wrote:

On Sun, Aug 20, 2000 at 01:26:05PM +0200, Sjoerd Mullender wrote: > Here's another pretty serious bug. Can you verify that this time it > isn't my configurations? It isn't your config, this is a genuine bug. I'll be checking in a quick fix in a few minutes, and start thinking about a test case that would've caught this. > Try this: > from encodings import cp1006, cp1026 > I get the error > ImportError: cannot import name cp1026 > but if I try to import the two modules separately I get no error. Yes. 'findfromargs' wasn't trying hard enough to find out what the argument to an import were. Previously, all it had to do was scan the bytecodes immediately following an 'IMPORTNAME' for IMPORTFROM statements, and record its names. However, now that IMPORTFROM generates a STORE, it stops looking after the first IMPORTFROM. This worked fine for normal object-retrieval imports, which don't use the list generated by findfromargs, but not for dynamic loading tricks such as 'encodings' uses. The fix I made was to unconditionally jump over 5 bytes, after an IMPORTFROM, rather than 2 (2 for the oparg, 1 for the next instruction (a STORE) and two more for the oparg for the STORE) This does present a problem for the proposed change in semantics for the 'as' clause, though. If we allow all expressions that yield valid l-values in import-as and from-import-as, we can't easily find out what the import arguments are by examining the future bytecode stream. (It might be possible, if we changed the POPTOP to, say, ENDIMPORT, that pops the module from the stack and can be used to end the search for import arguments. However, I find this hackery a bit appalling :) Why are we constructing a list of import arguments at runtime, from compile-time information, if all that information is available at compile time too ? And more easily so ? What would break if I made IMPORTNAME retrieve the from-arguments from a list, which is built on the stack by comimportstmt ? Or is there a more convenient way of passing a variable list of strings to a bytecode ? It won't really affect performance, since findfromargs is called for all imports anyway. -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

Python-Dev mailing list Python-Dev@python.org http://www.python.org/mailman/listinfo/python-dev