提案：内联导入 [英] Proposal: Inline Import
问题描述
这是一个异端的想法。
我想要一种在需要
功能的地方导入模块的方法，而不是还记得提前导入。这可能会消除我编码过程中的一个步骤。目前，我的流程是我改变代码并稍后扫描我的更改以对
import语句进行匹配更改。扫描步骤容易出错且耗时。
通过内联导入，我可以在没有额外扫描步骤的情况下更改代码。
此外，我建议导入内联的语法应该是一个
表达式，其中包含一个点后跟一个可选的点名。对于
示例：
name_expr = .re.compile（''[a-zA-Z] +''）
>
右边的表达式导致re.compile要在
之前导入调用编译函数。它类似于：
从重新导入编译为__hidden_re_compile
name_expr = __hidden_re_compile（''[a-zA-Z] +''）
示例表达式可以出现在任何模块中，无论
是否模块导入re。模块或指定不同的
意思是名称re。或者编译。
我还建议内联导入表达式对
本地或全局命名空间不起作用，内联导入也不应受到影响
本地或全局命名空间。如果用户想要影响名称空间，他们必须使用明确指定名称的其他语法来执行此操作，例如：
compile = .re.compile
为了尽早发现错误，对于
Python解析器生成执行实际导入的字节代码会很有用
加载包含内联导入表达式的模块。这会早点发现
拼写错误的模块名称。如果模块还将导入的
名称缓存在字典中，则导入
内联而不是导入模块顶部不会有速度损失。
我相信这可以帮助语言的许多方面：
- 编码工作流程将会改进，正如我所提到的。
- 代码将变得更加独立。自包含的代码更容易
作为食谱移动或张贴。
- 对新内置的需求会减少，因为模块将只是
可以像内置的那样访问。
想法？
Shane
Shane Hathaway写道：思考？
< blockquote class =post_quotes> import re; name_expr = re.compile（''[a-zA-Z] +''）
name_expr
< _sre.SRE_Pattern对象位于0x00F9D338>
导入语句可以在代码中的任何地方调用，为什么你会为b $ b添加一些奇怪的语法糖，它实际上并没有带来任何东西？
Shane Hathaway< sh *** @ hathawaymix.org>写道：这是一个异端的想法。
不是真的。
我想要一种在我需要
功能的地方导入模块的方法，而不是记住提前导入。这可能会消除我编码过程中的一个步骤。目前，我的流程是
我更改了代码，然后扫描我的更改，以便对import语句进行匹配更改。扫描步骤容易出错并且耗费时间。通过内联导入，我可以在没有
额外扫描步骤的情况下更改代码。
正如其他人所指出的那样，你可以修复你的过程。那你的
过程不能很好地用Python不是很好的理由来改变你的b $ b Python。
此外，我建议你导入内联的语法应该是一个包含点后跟一个可选的点名的表达式。
例如：
name_expr = .re.compile（''[a- zA-Z] +''）
右边的表达式导致re.compile在调用编译函数之前导入。它类似于：
从重新导入编译为__hidden_re_compile
name_expr = __hidden_re_compile（''[a-zA-Z] +''）
示例表达式可以存在于任何模块中，无论模块是否导入re表达式。模块或为名称re分配不同的含义。或编译。
这实际上是一个有趣的想法，但我将不得不给它一个
-1。
问题是，它真的只适用于一个极端情况 - 你需要在你的代码中只需要一个模块引用一个模块。我不想看到
代码跳过导入来执行.re.compile六次
而不是正确导入名称。事实上，避免这种情况只会让你的过程变得更糟：你必须返回
并扫描.module的多种用途并修复import语句。
我还建议内联导入表达式不应对本地或全局命名空间产生影响，内联导入也不应受本地或全局命名空间的影响。如果用户想要影响命名空间，他们必须使用明确指定名称的附加语法来实现，例如：
compile = .re.compile
现在可以使用from re import compile来执行此操作。
为了尽早发现错误，对于Python解析器生成字节会很有用在加载包含内联导入表达式的模块时执行实际导入的代码。这将尽早捕获拼写错误的模块名称。如果模块还将导入的名称缓存在字典中，则
导入内联而不是导入模块顶部不会有速度损失。
编号不，不，不。对于那些保持计数的人来说，这是-4。
这与导入语句的语义不同，
表示上面的例子被破坏了。这是一件坏事。
这意味着某些表达式是魔术，因为它们是在编译时自动评估的，而不是执行 br />
时间。这是一件坏事。
我不确定你的缓存会做什么。模块已经缓存在
sys.modules中。隐式导入必须像常规导入一样查找模块
名称。之后的名称必须是在该模块中查找的
- 这两个都是字典查找。什么
你会缓存 - 以及哪里 - 会明显改善？
我相信这可以帮助语言的许多方面：
- 编码工作流程正如我所提到的，会有所改善。
我认为它会变得更糟。
- 代码将变得更加独立。自包含代码更容易移动或作为食谱发布。
如果你真的想这样做，请使用__import__。
- 对内置新内容的需求会减少，因为模块将只是
可以像内置的那样访问。
我没有看到人们经常要求新的内置设备认为
这是一个问题需要修理。
< mike
-
Mike Meyer< mw*@mired.org> http://www.mired.org/home/mwm/
独立的WWW / Perforce / FreeBSD / Unix顾问，电子邮件以获取更多信息。
Shane Hathaway写道：
我想要一种在我需要
功能的地方导入模块的方法，而不是记得提前导入。
你已经可以做到了;导入语句不必位于Python脚本的顶部
。这个提议在抵达时已经死了。
-
Erik Max Francis&& ma*@alcyone.com && http://www.alcyone.com/max/
美国加利福尼亚州圣何塞市&& 37 20 N 121 53 W&& AIM erikmaxfrancis
我们/继续追逐早晨的原因
- Sandra St. Victor
Here''s a heretical idea.
I''d like a way to import modules at the point where I need the
functionality, rather than remember to import ahead of time. This might
eliminate a step in my coding process. Currently, my process is I
change code and later scan my changes to make matching changes to the
import statements. The scan step is error prone and time consuming.
By importing inline, I''d be able to change code without the extra scan step.
Furthermore, I propose that the syntax for importing inline should be an
expression containing a dot followed by an optionally dotted name. For
example:
name_expr = .re.compile(''[a-zA-Z]+'')
The expression on the right causes "re.compile" to be imported before
calling the compile function. It is similar to:
from re import compile as __hidden_re_compile
name_expr = __hidden_re_compile(''[a-zA-Z]+'')
The example expression can be present in any module, regardless of
whether the module imports the "re" module or assigns a different
meaning to the names "re" or "compile".
I also propose that inline import expressions should have no effect on
local or global namespaces, nor should inline import be affected by
local or global namespaces. If users want to affect a namespace, they
must do so with additional syntax that explicitly assigns a name, such as:
compile = .re.compile
In the interest of catching errors early, it would be useful for the
Python parser to produce byte code that performs the actual import upon
loading modules containing inline import expressions. This would catch
misspelled module names early. If the module also caches the imported
names in a dictionary, there would be no speed penalty for importing
inline rather than importing at the top of the module.
I believe this could help many aspects of the language:
- The coding workflow will improve, as I mentioned.
- Code will become more self-contained. Self-contained code is easier
to move around or post as a recipe.
- There will be less desire for new builtins, since modules will be just
as accessible as builtins.
Thoughts?
Shane
Shane Hathaway wrote:Thoughts?
import re; name_expr = re.compile(''[a-zA-Z]+'')
name_expr <_sre.SRE_Pattern object at 0x00F9D338>
the import statement can be called anywhere in the code, why would you
add strange syntactic sugar that doesn''t actually bring anything?
Shane Hathaway <sh***@hathawaymix.org> writes:Here''s a heretical idea.
Not really.
I''d like a way to import modules at the point where I need the
functionality, rather than remember to import ahead of time. This
might eliminate a step in my coding process. Currently, my process is
I change code and later scan my changes to make matching changes to
the import statements. The scan step is error prone and time
consuming. By importing inline, I''d be able to change code without the
extra scan step.
As others have pointed out, you can fix your process. That your
process doesn''t work well with Python isn''t a good reason for changing
Python.
Furthermore, I propose that the syntax for importing inline should be
an expression containing a dot followed by an optionally dotted name.
For example:
name_expr = .re.compile(''[a-zA-Z]+'')
The expression on the right causes "re.compile" to be imported before
calling the compile function. It is similar to:
from re import compile as __hidden_re_compile
name_expr = __hidden_re_compile(''[a-zA-Z]+'')
The example expression can be present in any module, regardless of
whether the module imports the "re" module or assigns a different
meaning to the names "re" or "compile".
It''s actually an intriguing idea, but I''m going to have to give it a
-1.
The thing is, it''s really only useful in a corner case - where you
want to refer to a module exactly once in your code. I''d hate to see
code that skips doing the import to do .re.compile a half-dozen times
instead of importing the name properly. In fact, avoiding this
situation just makes your process even worse: you''d have to go back
and scan for multiple uses of .module and fix the import statements.
I also propose that inline import expressions should have no effect on
local or global namespaces, nor should inline import be affected by
local or global namespaces. If users want to affect a namespace, they
must do so with additional syntax that explicitly assigns a name, such
as:
compile = .re.compile
You can do this now, with "from re import compile".
In the interest of catching errors early, it would be useful for the
Python parser to produce byte code that performs the actual import
upon loading modules containing inline import expressions. This would
catch misspelled module names early. If the module also caches the
imported names in a dictionary, there would be no speed penalty for
importing inline rather than importing at the top of the module.
No. No, no and no. That''s -4, for those keeping count.
This is different from the semantics of the import statment, which
means your examples above are broken. This is a bad thing.
This means that some expressions are "magic", in that they are
automatically evaluated at compile time instead of execution
time. This is a bad thing.
I''m not sure what your cache would do. Modules are already cached in
sys.modules. Your implicit import would have to look up the module
name just like a regular import. The name following then has to be
looked up in that module - both of which are dictionary lookups. What
would you cache - and where - that would noticably improve on that?
I believe this could help many aspects of the language:
- The coding workflow will improve, as I mentioned.
I think it''ll get worse.
- Code will become more self-contained. Self-contained code is easier
to move around or post as a recipe.
If you really want to do this, use __import__.
- There will be less desire for new builtins, since modules will be
just as accessible as builtins.
I don''t see people asking for new builtins often enough to think that
this is a problem that needs fixing.
<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Shane Hathaway wrote:
I''d like a way to import modules at the point where I need the
functionality, rather than remember to import ahead of time.
You can already do this; import statements don''t have to be at the top
of a Python script. This proposal is pretty much dead on arrival.
--
Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
There''s a reason why we / Keep chasing morning
-- Sandra St. Victor
这篇关于提案：内联导入的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
