[Patches] [Patch #101243] Use a compile time mechanism to 'find "import-from" args'

[noreply@sourceforge.net]

Patch #101243 has been updated. 

Project: 
Category: core (C code)
Status: Open
Summary: Use a compile time mechanism to 'find "import-from" args'

Follow-Ups:

Date: 2000-Aug-20 13:57
By: twouters

Comment:
This patch changes the mechanism used to find the 'import-arguments' as passed to __import__ (and used by 'ni' and such dynamic import mechanisms.) The current mechanism looks into the 'future' bytecode stream (from the IMPORT_NAME statement onward) looking for IMPORT_FROM statements. The problem is that this limits the extend in which we can change IMPORT_FROM, and that this is a runtime check for information which was available at compile-time.

Instead, we create a list of import-from arguments, and push it on the stack. The list creation is still done at runtime (it has to be, I think ?) but it's a simple push-constants-on-the-stack-and-BUILD_LIST operation.

The result is that all 'import arguments' (the names imported-from another module) are present not only as normal 'names' in the co_names list, but also as PyString objects in the co_consts list. And that pystone runs a few promille faster on my machine. And that more trickery is allowed in imports, such as those that patch #101234 allows.

-------------------------------------------------------

Date: 2000-Aug-21 17:18
By: tim_one

Comment:
Leaving unassigned for the moment.
I'm all in favor of moving stuff from runtime to compile-time, I just don't have time to look at this now.

OK, not leaving unassigned:  Guido, is there a reason Thomas couldn't build a *tuple* of names at compile-time and stuff that into co_consts?
-------------------------------------------------------

Date: 2000-Aug-21 17:21
By: tim_one

Comment:
Leaving unassigned for the moment.
I'm all in favor of moving stuff from runtime to compile-time, I just don't have time to look at this now.

OK, not leaving unassigned:  Guido, is there a reason Thomas couldn't build a *tuple* of names at compile-time and stuff that into co_consts?
-------------------------------------------------------

Date: 2000-Aug-21 17:53
By: gvanrossum

Comment:
Cool, but needs some work before you can check it in. Notes:

- Yes, a tuple constant would be fine. (Note: co_names and co_consts are really redundant; all that's needed is co_consts.)

- In ceval.c, why not place "u = POP()" *after* the test for x==NULL? Then you don't need to DECREF it when x==NULL.

- You left the fprintf in com_pop() uncommented!

- Barry just bumped the MAGIC number. There's no need to do this twice a week if no release occurred. :)
-------------------------------------------------------

Date: 2000-Aug-22 07:39
By: twouters

Comment:
- Okay, I'll rewrite it to create a tuple. Note, however ! This means that the import mechanism gets passed in a tuple, instead of a list. I'm not sure if that will break anything, or influence user-code in any way, because I can't say I fully understand the import mechanisms yet ;) But I did notice that PyImport_ImportModule() takes care to build a list instead of a tuple, to pass to PyImport_ImportModuleEx()

- moving the POP(): fine. I'm never quite sure when to POP an item or not. I was under the impression that you needed to pop all items the bytecode is 'supposed' to pop (and push back the number of items it's supposed to push, even if they are NULL) before raising an exception. But that's just the impression I got from reading the code, not from reading the exception mechanism.

- The entries in co_names are not really redundant. The co_names entries are used for the actual IMPORT_FROM and STORE_NAME opcodes, this new tuple (or list) only for the IMPORT_NAME opcode. I don't think it's worth the effort to combine the two, because it would require either rewriting the STORE opcodes to use a const rather than a name, or find out in some way which 'names' are used in imports. Anyway, since they're both PyStrings, and both likely to be interned, it's just a pointer duplication.

- fprintf: oops. Will fix.

- Bumping the magic: I'm not so certain about not upping the bytecode magic: we're not using up a scarce resource, here, because it's upped according to date anyway. Is not upping it worth the small chance that someone imports new bytecode in an old interpreter and gets weird behaviour ?

Patch follows later: I'm trying not to neglect my other patches in the mean time, and that's proven tricky with the number of conflicting checkins in the last two weeks :-)

-------------------------------------------------------

Date: 2000-Aug-26 15:40
By: twouters

Comment:
Okay, this patch creates a tuple-constant instead of constructing a list at runtime, makes import.c use a tuple as well, and moves the POP(). However, it still ups the bytecode magic :-)


-------------------------------------------------------

Date: 2000-Aug-26 15:44
By: twouters

Comment:
Oh, and giving it back to Guido.

-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101243&group_id=5470