[Python-Dev] Is outlawing-nested-import-* only an implementation issue?

[Ka-Ping Yee]

On Thu, 22 Feb 2001, Tim Peters wrote:
> That determination is done at compile-time, not runtime.  In the presence of
> "exec" and "import *" in some contexts, compile-time determination is
> stymied and there is no runtime support for a "slow" lookup.

Would the existence of said runtime support hurt anybody?  Don't
we already do slow lookup in some situations anyway?

> Note that the restrictions are *not* against lexical nesting, they're
> against particular uses of "exec" and "import *" (the latter of which is so
> muddy the Ref Man said it was undefined a long, long time ago).

(To want to *take away* the ability to do import-* at all, in order
to protect programmers from their own bad habits, is a different
argument.  I think we all already agree that it's bad form.  But
the recent clamour has shown that we can't take it away just yet.)

> There are tradeoffs here among:
> 
>     conceptual clarity
>     runtime efficiency
>     implementation complexity
>     rate of cyclic garbage creation
> 
> Your message favors "conceptual clarity" over all else; the implementation
> doesn't.  Python also limits strings to the size of a platform int <0.9
> wink>.

Yes, i do think conceptual clarity is important.  The way Python
leans towards conceptual simplicity is a big part of its success,
i believe.  The less there is for someone to fit into their brain,
the less time they can spend worrying about how the language will
behave and the more they can focus on getting the job done.

And i don't think we have to sacrifice much of the others to do it.
In fact, often conceptual clarity leads to a simpler implementation,
and sometimes even a faster implementation.  Now i haven't actually
done the implementation so i can't tell you whether it will be faster,
but it seems to me that it's likely to be simpler and could stand a
chance of being faster.


-- ?!ng

"The only `intuitive' interface is the nipple.  After that, it's all learned."
    -- Bruce Ediger, on user interfaces