Re: Packaging and importing
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: Packaging and importing
- From: Rici Lake <lua@...>
- Date: 2005年8月16日 14:16:24 -0500
On 16-Aug-05, at 1:12 PM, Chris Marrin wrote:
The one nice feature that Python has is:
from math import *
which imports all names from math into the namespace. I suppose that
could be done with:
import("math", "all")
or something like that.
This cannot be done at compile time, since the compiler has no real way
of knowing what might be in a package at run time. So it could not
fabricate the necessary locals.
I personally can live without this feature, though. You end up with the
local math, which you can use to access specific functions (math.log);
if you wanted to reference them directly, you would need to import them
explicitly, which is simply saying that locals need to be explicitly
declared.
However, I'm a trifle uneasy about the 'local log = math.log'
optimization, because it makes overriding package methods unreliable.
Say, for example, that I have a reimplementation of string.find (as an
example). If a package "imports" find from string, and it is loaded
before I modify the string namespace, the package will use the base
version; otherwise, it will use my "improved" version.
This may not strike anyone as an issue, but consider the case where I
want to upgrade a package in a running program. I can (possibly) do
that by changing the contents of the package table without changing its
identity, but I cannot do it reliably if elements of the package table
have been assigned to locals (which have presumably become closed
upvalues).
It might be more interesting/useful to think about how to optimize the
lookup of pkg.method, specifically in the common case where pkg is an
upvalue and method is a constant string known at compile time. In the
current VM implementation, the fact that pkg is an upvalue will force
an additional vm op (GETUPVAL), in addition to the hash lookup of
method.