[Patches] [Patch #101135] 'import x as y' and 'from x import y as z'

noreply@sourceforge.net noreply@sourceforge.net
Thu, 17 Aug 2000 12:13:52 -0700


Patch #101135 has been updated. 

Project: 
Category: core (C code)
Status: Accepted
Summary: 'import x as y' and 'from x import y as z'

Follow-Ups:

Date: 2000-Aug-09 20:23
By: twouters

Comment:
This patch adds the oft-proposed 'import as' syntax, to both 'import module' and 'from module import ...', but without making 'as' a reserved word (by using the technique Tim Peters proposed on python-dev.)

'import spam as egg' is a very simple patch to compile.c, which doesn't need changes to the VM, but 'from spam import dog as meat' needs a new bytecode, which this patch calls 'FROM_IMPORT_AS'. The bytecode loads an object from a module onto the stack, so a STORE_NAME can store it later. This can't be done by the normal FROM_IMPORT opcode, because it needs to take the special case of '*' into account. Also, because it uses 'STORE_NAME', it's now possible to mix 'import' and 'global', like so:

global X
from foo import X as X

The patch still generates the old code for

from foo import X

(without 'as') mostly to save on bytecode size, and for the 'compatibility' with mixing 'global' and 'from .. import'... I'm not sure what's the best thing to do.

The patch doesn't include a test suite or documentation, yet.

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

Date: 2000-Aug-11 22:04
By: twouters

Comment:
I now think the best thing to do is to split the 'IMPORT_FROM' opcode into two opcodes: 'IMPORT_ALL', which is used for 'from module import *', and 'IMPORT_FROM' (or another name, if that's desired) which loads a single name.

IMPORT_ALL would store the retrieved objects into the local namespace directly, like IMPORT_FROM currently does; it doesn't use the stack other than to retrieve the module it loads the symbols from.

IMPORT_FROM would act more like 'IMPORT_NAME', in that the object retrieved from the module is not stored directly in the local namespace, but instead pushed on the stack (that's what the IMPORT_FROM_AS bytecode in the current patch does) -- that means that for all normal 'from' imports, a STORE is generated, and a 'global' works on them just like with normal variable assignment. In the current patch, this is only true for 'from module import x as y' statements, not for the normal form.

Assigned to Guido, since it's ultimately his decision (everyone else already voted ;-)

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

Date: 2000-Aug-15 22:12
By: tim_one

Comment:
Reminding Guido this is still on his plate.

Thomas, I agree with you that splitting IMPORT_FROM is a good idea -- the "*" and "name" cases are indeed very different.  Since Guido hasn't gotten to this yet, how about changing the patch before he notices?  The  votes you got before were based on the visible semantics, not the implementation, so no need to vote again.
-------------------------------------------------------

Date: 2000-Aug-15 22:25
By: twouters

Comment:
Actually, I finished an updated patch that did that about two hours ago, but Blackadder intervened, and I forgot to upload it afterwards :P

This patch does not contain doc changes or test cases yet, but the changes to the core are finished, as far as I'm concerned. I'll try to finish the docs and tests tomorrow. 

(I have to say this is the first patch where the doc changes look more attractive than the test case. I need to start a syntax-highlighting editor just to be able to *read* test_pkg, let alone extend it ;)



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

Date: 2000-Aug-17 19:13
By: gvanrossum

Comment:
Go for it.  This is a scary precedent (a new keyword without keyword status) but I think the basic proposal is good.  I haven't reviewed the quality of the patch, but I presume it's been checked by others (and it can always be fixed later).
-------------------------------------------------------

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

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