[Python-Dev] Re: [Patches] [Patch #101234] Allow all assignment expressions after 'import something as'

[Thomas Wouters]

On Sun, Aug 20, 2000 at 01:02:32PM -0700, noreply@sourceforge.net wrote:

> Summary: Allow all assignment expressions after 'import something as'

> Date: 2000-Aug-19 21:29
> By: twouters
> 
> Comment:
> This absurdly simple patch (4 lines changed in 2 files) turns 'import-as'
> and 'from-import-as' into true assignment expressions: the name given
> after 'as' can be any expression that is a valid l-value:

> >>> from sys import version_info as (maj,min,pl,relnam,relno)          
> >>> maj,min,pl,relnam,relno
> (2, 0, 0, 'beta', 1)

[snip other examples]

> This looks so natural, I would almost treat this as a bugfix instead of a
> new feature ;)

> -------------------------------------------------------
> 
> Date: 2000-Aug-20 20:02
> By: nowonder
> 
> Comment:
> Looks fine. Works as I expect. Doesn't break old code. I hope Guido likes
> it (assigned to gvanrossum).

Actually, it *will* break old code. Try using some of those tricks on, say,
'encodings', like so (excessively convoluted to prove a point ;):

>>> x = {}
>>> from encodings import cp1006 as x[oct(1)], cp1026 as x[hex(20)]
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: cannot import name cp1026

I've another patch waiting which I'll upload after some cleanup, which
circumvents this. The problem is that find_from_args is having a hard time
figuring out how 'import' is being called, exactly. So instead, I create a
list *before* calling import, straight from the information available at
compile-time. (It's only a list because it is currently a list, I would
prefer to make it a tuple instead but I donno if it would break stuff)

That patch is necessary to be able to support this new behaviour, but I
think it's worth checking in even if this patch is rejected -- it speeds up
pystone ! :-) Basically it moves the logic of finding out what the import
arguments are to com_import_stmt() (at compiletime), rather than the
'IMPORT_NAME' bytecode (at runtime).

The only downside is that it adds all 'from-import' arguments to the
co_consts list (as PyString objects) as well as where they already are, the
co_names list (as normal strings). I don't think that's a high price to pay,
myself, and mayhaps the actual storage use could be reduced by making the
one point to the data of the other. Not sure if it's worth it, though.

I've just uploaded the other patch, it can be found here:
http://sourceforge.net/patch/?func=detailpatch&patch_id=101243&group_id=5470

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!