PEP 338：使用'-m'在包内执行模块 [英] PEP 338: Executing modules inside packages with '-m'
问题描述
Python 2.4'的-m命令行开关仅适用于直接在sys.path上的模块。
尝试将其与包内的模块一起使用将失败并显示Module not
找到了错误。这个PEP旨在解决Python 2.5的问题。
以前，将PEP的草稿版本发布到python-dev和python-list
didn'实际上并没有产生任何回应。我不确定这是否是一个迹象
人们没有看到对顶层模块的限制是一个问题（并且因此认为是b $ b PEP是不必要的），或认为处理包的扩展名是明显的（因此看不需要评论）。
或者，它可能只是这是一个迹象表明Python 2.4还没有足够长的时间来讨论
任何人都要关心我正在谈论的事情:)
无论如何，所有评论都表示赞赏（即使是简单的对我来说也不错）。
干杯，
尼克。
********************************************* *** *********************
PEP：338
标题：执行包内的模块''-m''
版本：$修订版：1.2 $
最后修改日期：$ Date：2004/12/11 20:31:10 $
作者：Nick Coghlan< nc ****** @ email.com>
状态：草稿
类型：标准追踪
Con tent-Type：text / x-rst
创建日期：2004年10月16日
Python版本：2.5
后历史：8 -Nov-2004
摘要
========
此PEP定义了在包内执行模块的语义as
带有`-m``命令行开关的脚本。
建议的语义是导入的包含
$ b在执行脚本之前$ b。
理由
=========
Python 2.4添加命令行开关``-m``允许模块使用Python模块命名空间定位，以执行脚本。
激励示例是标准库模块，如作为``pdb``
和``profile``。
许多用户和开发者要求扩展
功能还支持位于包内的运行模块。一个提供的例子是pychecker'的``pychecker.checker``模块。这个
的功能被排除在Python 2.4实现之外，因为
适当的语义并不完全清楚。
关于python-dev是最好将
扩展推迟到Python 2.5，并通过PEP流程帮助制作
确保我们做对了。
此提案的范围
==========================
在Python 2.4中，使用``-m``定位的模块就像在命令行上提供了它的文件名一样。这个
PEP的目标是尽可能接近使声明对包内的模块保持
为真。
之前的讨论建议应该注意的是，这个PEP对于以下任何一个都不是**
：
- 改变制作的习语Python模块也可用作脚本
（参见PEP 299 [1] _）。
- 将``-m``的限制解除为模块输入PY_SOURCE或
PY_COMPILED（即``.py``，``.pyc``，``.pyo``，``.pyw``）。
- 解决`-m``无法理解zip导入的问题或
Python的sys.metapath。
上面列出的问题被认为与此PEP解决的特定
功能正交。
当前行为
========= ========
在描述新的语义之前，它值得涵盖Python 2.4的现有
语义（因为它们是真正水流仅由
源代码定义。
当在命令行上使用``-m``时，它立即终止
选项列表（如``-c``）。该参数被解释为
a顶级Python模块的名称（即可以在
``sys_path``上找到的名称）。
如果找到模块，并且类型为``PY_SOURCE``或
``PY_COMPILED``，那么命令行将被有效重新解释
来自``python< options> -m< module> < args>``到``python< options>
< filename> < ARGS>``。这包括设置``sys.argv [0]``正确
（一些脚本依赖于此 - Python自己的``regrtest.py``是一个
例）。
如果找不到模块，或者类型不正确，则会打印错误
。
提议的语义
==================
提出的语义非常简单：如果``-m``用于在包内执行
a模块作为脚本，然后在按照语义执行模块之前导入包含包
用于顶级模块。
这是必要的，因为Python的导入机器定位的方式
模块里面包。包可能会在初始化期间修改自己的__path__
变量。此外，路径可能受
`` * .pth``文件的影响。因此，Python可靠地确定模块的唯一方法是导入包含的包，并检查其__path__变量。
请注意，包*不会*导入到``__main__``模块'的
名称空间中。
执行模块可见的这些语义的效果是：
- 包含的包将在sys.modules中
- 软件包初始化的任何外部影响（例如安装
导入钩子，记录器，atexit处理程序等）
参考实现
========================
SourceForge上有一个参考实现[2] ] _。在这个
实现中，如果``-m``开关无法在顶层找到所请求的
模块，它会有效地重新解释来自
的命令。
``python -m< script>``到``python -m execmodule< script>``。 （有
是一个警告：当以这种方式重新解释时，``sys.argv [0]``可能不会
实际上包含``execmodule`的文件名这只会影响
``execmodule``本身，而不是所请求的模块。
``execmodule``是一个建议的标准库模块，包含一个
单个函数（也称为``execmodule``）。当作为
脚本调用时，该模块查找并执行作为
第一个参数提供的模块。它通过删除``sys.argv [0]``
来调整``sys.argv``并用模块的文件名替换新的``sys.argv [0]``
而不是它的Python名称。
函数``execmodule``就像``execfile``，但是使用Python
模块命名空间用于定位脚本而不是文件系统。它
有一个额外的可选参数``set_argv0``，它导致找到的模块的
文件名被写入``sys.argv [0]``之前
模块被执行。
使用混合C / Python实现，因为Python模块更加灵活，并且更加灵活。比同等的C代码可扩展。它
也允许``execmodule``函数可用。脚本
执行其他脚本（例如``profile``，``pdb``）有
选项来使用这个函数提供``-m``样式支持
标识要执行的脚本。
execmodule的Python代码也被发布为
Python 2.4食谱食谱[3] _。
公开问题
===========
- 选择包含
``execmodule``的标准库模块的名称。参考实现使用``execmodule``。
python-dev上提出的替代名称是``runpy``。
替代品
============
主要的替代实现被认为忽略了包''
__path__变量，并且仅在主要内容中查找包目录。一个带有这种行为的
Python脚本可以在讨论
的``execmodule``食谱中找到[3] _。
这种方法没有被使用，因为它不符合
``-m``开关的主要目标 - 允许使用完整的Python命名空间
找到要执行的模块。
参考资料
==========
.. 。[1]模块中的特殊__main __（）函数
（ http://www.python.org/peps/pep-0299.html ）
... [2]原生``-m` `execmodule支持
（ http://sourceforge.net/tracker/?func...70&atid=305470 ）
... [ 3] execmodule Python食谱食谱
（ http://aspn.activestate.com/ASPN/Coo.../Recipe/307772 ）
版权所有
=========
本文档已被置于公共领域。
.. 。
本地变量：
模式：缩进文本
缩进标签模式：无
句子 - 结束双倍空间：t
填充栏：70
结束：
-
Nick Coghlan | nc******@email.com |澳大利亚布里斯班
--------------------------------------- ------------------------
http://boredomandlaziness.skystorm.net
修订版：1.2
< blockquote>
Last-Modified：
日期：2004/12/11 20:31:10
Python 2.4''s -m command line switch only works for modules directly on sys.path.
Trying to use it with modules inside packages will fail with a "Module not
found" error. This PEP aims to fix that for Python 2.5.
Previously, posting of a draft version of the PEP to python-dev and python-list
didn''t actually generate any responses. I''m not sure if that''s an indication
that people don''t see the restriction to top-level modules as a problem (and
hence think the PEP is unecessary), or think the extension to handle packages is
obvious (and hence see no need to comment).
Or, it could just be a sign that Python 2.4 hasn''t been out long enough for
anyone to care what I''m yabbering on about :)
Anyway, all comments are appreciated (even a simple "Sounds good to me").
Cheers,
Nick.
************************************************** *********************
PEP: 338
Title: Executing modules inside packages with ''-m''
Version: $Revision: 1.2 $
Last-Modified: $Date: 2004/12/11 20:31:10 $
Author: Nick Coghlan <nc******@email.com>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 16-Oct-2004
Python-Version: 2.5
Post-History: 8-Nov-2004
Abstract
========
This PEP defines semantics for executing modules inside packages as
scripts with the ``-m`` command line switch.
The proposed semantics are that the containing package be imported
prior to execution of the script.
Rationale
=========
Python 2.4 adds the command line switch ``-m`` to allow modules to be
located using the Python module namespace for execution as scripts.
The motivating examples were standard library modules such as ``pdb``
and ``profile``.
A number of users and developers have requested extension of the
feature to also support running modules located inside packages. One
example provided is pychecker''s ``pychecker.checker`` module. This
capability was left out of the Python 2.4 implementation because the
appropriate semantics were not entirely clear.
The opinion on python-dev was that it was better to postpone the
extension to Python 2.5, and go through the PEP process to help make
sure we got it right.
Scope of this proposal
==========================
In Python 2.4, a module located using ``-m`` is executed just as if
its filename had been provided on the command line. The goal of this
PEP is to get as close as possible to making that statement also hold
true for modules inside packages.
Prior discussions suggest it should be noted that this PEP is **not**
about any of the following:
- changing the idiom for making Python modules also useful as scripts
(see PEP 299 [1]_).
- lifting the restriction of ``-m`` to modules of type PY_SOURCE or
PY_COMPILED (i.e. ``.py``, ``.pyc``, ``.pyo``, ``.pyw``).
- addressing the problem of ``-m`` not understanding zip imports or
Python''s sys.metapath.
The issues listed above are considered orthogonal to the specific
feature addressed by this PEP.
Current Behaviour
=================
Before describing the new semantics, it''s worth covering the existing
semantics for Python 2.4 (as they are currently defined only by the
source code).
When ``-m`` is used on the command line, it immediately terminates the
option list (like ``-c``). The argument is interpreted as the name of
a top-level Python module (i.e. one which can be found on
``sys.path``).
If the module is found, and is of type ``PY_SOURCE`` or
``PY_COMPILED``, then the command line is effectively reinterpreted
from ``python <options> -m <module> <args>`` to ``python <options>
<filename> <args>``. This includes setting ``sys.argv[0]`` correctly
(some scripts rely on this - Python''s own ``regrtest.py`` is one
example).
If the module is not found, or is not of the correct type, an error
is printed.
Proposed Semantics
==================
The semantics proposed are fairly simple: if ``-m`` is used to execute
a module inside a package as a script, then the containing package is
imported before executing the module in accordance with the semantics
for a top-level module.
This is necessary due to the way Python''s import machinery locates
modules inside packages. A package may modify its own __path__
variable during initialisation. In addition, paths may affected by
``*.pth`` files. Accordingly, the only way for Python to reliably
locate the module is by importing the containing package and
inspecting its __path__ variable.
Note that the package is *not* imported into the ``__main__`` module''s
namespace. The effects of these semantics that will be visible to the
executed module are:
- the containing package will be in sys.modules
- any external effects of the package initialisation (e.g. installed
import hooks, loggers, atexit handlers, etc.)
Reference Implementation
========================
A reference implementation is available on SourceForge [2]_. In this
implementation, if the ``-m`` switch fails to locate the requested
module at the top level, it effectively reinterprets the command from
``python -m <script>`` to ``python -m execmodule <script>``. (There
is one caveat: when reinterpreted in this way, ``sys.argv[0]`` may not
actually contain the filename of ``execmodule``. This only affects
``execmodule`` itself, not the requested module).
``execmodule`` is a proposed standard library module that contains a
single function (also called ``execmodule``). When invoked as a
script, this module finds and executes the module supplied as the
first argument. It adjusts ``sys.argv`` by deleting ``sys.argv[0]``
and replacing the new ``sys.argv[0]`` with the module''s filename
instead of its Python name.
The function ``execmodule`` is like ``execfile``, but uses the Python
module namespace to locate the script instead of the filesystem. It
has an additional optional argument ``set_argv0`` which causes the
filename of the located module to be written to ``sys.argv[0]`` before
the module is executed.
A hybrid C/Python implementation is used as the Python module is much
more flexible and extensible than the equivalent C code would be. It
also allows the ``execmodule`` function to be made available. Scripts
which execute other scripts (e.g. ``profile``, ``pdb``) have the
option to use this function to provide ``-m`` style support for
identifying the script to be executed.
The Python code for ``execmodule`` has also been posted as a
cookbook recipe for Python 2.4 [3]_.
Open Issues
===========
- choosing a name for the standard library module containing
``execmodule``. The reference implementation uses ``execmodule``.
An alternative name proposed on python-dev is ``runpy``.
Alternatives
============
The main alternative implementation considered ignored packages''
__path__ variables, and looked only in the main package directory. A
Python script with this behaviour can be found in the discussion of
the ``execmodule`` cookbook recipe [3]_.
This approach was not used as it does not meet the main goal of the
``-m`` switch -- to allow the full Python namespace to be used to
locate modules for execution.
References
==========
... [1] Special __main__() function in modules
(http://www.python.org/peps/pep-0299.html)
... [2] Native ``-m`` execmodule support
(http://sourceforge.net/tracker/?func...70&atid=305470 )
... [3] execmodule Python Cookbook Recipe
(http://aspn.activestate.com/ASPN/Coo.../Recipe/307772)
Copyright
=========
This document has been placed in the public domain.
...
Local Variables:
mode: indented-text
indent-tabs-mode: nil
sentence-end-double-space: t
fill-column: 70
End:
--
Nick Coghlan | nc******@email.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
Revision: 1.2
Last-Modified:
Date: 2004/12/11 20:31:10
这篇关于PEP 338：使用'-m'在包内执行模块的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
