[Python-checkins] python/nondist/peps pep-0302.txt,1.1,1.2
goodger@users.sourceforge.net
goodger@users.sourceforge.net
2002年12月21日 11:51:07 -0800
Update of /cvsroot/python/python/nondist/peps
In directory sc8-pr-cvs1:/tmp/cvs-serv10572
Modified Files:
pep-0302.txt
Log Message:
Spell checked
Index: pep-0302.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0302.txt,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** pep-0302.txt 20 Dec 2002 13:07:24 -0000 1.1
--- pep-0302.txt 21 Dec 2002 19:51:05 -0000 1.2
***************
*** 4,8 ****
Last-Modified: $Date$
Author: Just van Rossum <just@letterror.com>,
! Paul Moore <gustav@morpheus.demon.co.uk>
Status: Draft
Type: Standards Track
--- 4,8 ----
Last-Modified: $Date$
Author: Just van Rossum <just@letterror.com>,
! Paul Moore <gustav@morpheus.demon.co.uk>
Status: Draft
Type: Standards Track
***************
*** 25,29 ****
The only way to customize the import mechanism is currently to
! override the builtin __import__ function. However, overriding
__import__ has many problems. To begin with:
--- 25,29 ----
The only way to customize the import mechanism is currently to
! override the built-in __import__ function. However, overriding
__import__ has many problems. To begin with:
***************
*** 69,73 ****
The work on this PEP was partly triggered by the implementation of
! PEP 273 [2], which adds imports from Zip archives as a builtin
feature to Python. While the PEP itself was widely accepted as a
must-have feature, the implementation left a few things to desire.
--- 69,73 ----
The work on this PEP was partly triggered by the implementation of
! PEP 273 [2], which adds imports from Zip archives as a built-in
feature to Python. While the PEP itself was widely accepted as a
must-have feature, the implementation left a few things to desire.
***************
*** 103,115 ****
Before work on the design and implementation of this PEP was
! started, a new BuildApplication-like tool for MacOSX prompted one of
! the authors of this PEP (JvR) to expose the table of frozen modules
! to Python, in the imp module. The main reason was to be able to use
! the freeze import hook (avoiding fancy __import__ support), yet to
! also be able to supply a set of modules at runtime. This resulted
! in sf patch #642578 [6], which was mysteriously accepted (mostly
! because nobody seemed to care either way ;-). Yet it is completely
! superfluous when this PEP gets accepted, as it offers a much nicer
! and general way to do the same thing.
--- 103,116 ----
Before work on the design and implementation of this PEP was
! started, a new BuildApplication-like tool for MacOS X prompted one
! of the authors of this PEP (JvR) to expose the table of frozen
! modules to Python, in the imp module. The main reason was to be
! able to use the freeze import hook (avoiding fancy __import__
! support), yet to also be able to supply a set of modules at
! runtime. This resulted in sf patch #642578 [6], which was
! mysteriously accepted (mostly because nobody seemed to care either
! way ;-). Yet it is completely superfluous when this PEP gets
! accepted, as it offers a much nicer and general way to do the same
! thing.
***************
*** 117,121 ****
While experimenting with alternative implementation ideas to get
! builtin Zip import, it was discovered that achieving this is
possible with only a fairly small amount of changes to import.c.
This allowed to factor out the Zip-specific stuff into a new source
--- 118,122 ----
While experimenting with alternative implementation ideas to get
! built-in Zip import, it was discovered that achieving this is
possible with only a fairly small amount of changes to import.c.
This allowed to factor out the Zip-specific stuff into a new source
***************
*** 124,128 ****
An earlier design allowed non-string objects on sys.path. Such an
! object would have the neccesary methods to handle an import. This
has two disadvantages: 1) it breaks code that assumes all items on
sys.path are strings; 2) it is not compatible with the PYTHONPATH
--- 125,129 ----
An earlier design allowed non-string objects on sys.path. Such an
! object would have the necessary methods to handle an import. This
has two disadvantages: 1) it breaks code that assumes all items on
sys.path are strings; 2) it is not compatible with the PYTHONPATH
***************
*** 147,166 ****
overhead, it was chosen to not add an explicit hook and importer
object for the existing file system import logic (as iu.py has), but
! to simply fall back to the builtin logic if no hook on
sys.path_hooks could handle the path item. If this is the case, a
None value is stored in sys.path_importer_cache, again to avoid
repeated lookups. (Later we can go further and add a real importer
! object for the builtin mechanism, for now, the None fallback scheme
should suffice.)
A question was raised: what about importers that don't need *any*
! entry on sys.path? (Builtin and frozen modules fall into that
category.) Again, Gordon McMillan to the rescue: iu.py contains a
thing he calls the "metapath". In this PEP's implementation, it's a
list of importer objects that is traversed *before* sys.path. This
list is yet another new object in the sys.module: sys.meta_path.
! Currently, this list is empty by default, and frozen and builtin
module imports are done after traversing sys.meta_path, but still
! before sys.path. (Again, later we can add real frozen, builtin and
sys.path importer objects on sys.meta_path, allowing for some extra
flexibility, but this could be done as a "phase 2" project, possibly
--- 148,167 ----
overhead, it was chosen to not add an explicit hook and importer
object for the existing file system import logic (as iu.py has), but
! to simply fall back to the built-in logic if no hook on
sys.path_hooks could handle the path item. If this is the case, a
None value is stored in sys.path_importer_cache, again to avoid
repeated lookups. (Later we can go further and add a real importer
! object for the built-in mechanism, for now, the None fallback scheme
should suffice.)
A question was raised: what about importers that don't need *any*
! entry on sys.path? (Built-in and frozen modules fall into that
category.) Again, Gordon McMillan to the rescue: iu.py contains a
thing he calls the "metapath". In this PEP's implementation, it's a
list of importer objects that is traversed *before* sys.path. This
list is yet another new object in the sys.module: sys.meta_path.
! Currently, this list is empty by default, and frozen and built-in
module imports are done after traversing sys.meta_path, but still
! before sys.path. (Again, later we can add real frozen, built-in and
sys.path importer objects on sys.meta_path, allowing for some extra
flexibility, but this could be done as a "phase 2" project, possibly
***************
*** 185,194 ****
When an import statement is encountered, the interpreter looks up
! the __import__ function in the builtin name space. __import__ is
then called with four arguments, amongst which are the name of the
module being imported (may be a dotted name) and a reference to the
current global namespace.
! The builtin __import__ function (known as PyImport_ImportModuleEx in
import.c) will then check to see whether the module doing the import
is a package by looking for a __path__ variable in the current
--- 186,195 ----
When an import statement is encountered, the interpreter looks up
! the __import__ function in the built-in name space. __import__ is
then called with four arguments, amongst which are the name of the
module being imported (may be a dotted name) and a reference to the
current global namespace.
! The built-in __import__ function (known as PyImport_ImportModuleEx in
import.c) will then check to see whether the module doing the import
is a package by looking for a __path__ variable in the current
***************
*** 232,236 ****
importer.find_module("spam.eggs.ham") is called, "spam.eggs" has
already been imported and added to sys.modules. However, the
! find_module() method isn't neccesarily always called during an
actual import: meta tools that analyze import dependencies (such as
freeze, Installer or py2exe) don't actually load modules, so an
--- 233,237 ----
importer.find_module("spam.eggs.ham") is called, "spam.eggs" has
already been imported and added to sys.modules. However, the
! find_module() method isn't necessarily always called during an
actual import: meta tools that analyze import dependencies (such as
freeze, Installer or py2exe) don't actually load modules, so an
***************
*** 253,258 ****
- The __file__ attribute must be set. This must be a string, but it
! may be a dummy value, for example "<frozen>". The priviledge of
! not having a __file__ attribute at all is reserved for builtin
modules.
--- 254,259 ----
- The __file__ attribute must be set. This must be a string, but it
! may be a dummy value, for example "<frozen>". The privilege of
! not having a __file__ attribute at all is reserved for built-in
modules.
***************
*** 263,270 ****
- It should add an __importer__ attribute to the module, set to the
loader object. This is mostly for introspection, but can be used
! for importer-specific extra's, for example getting data associated
with an importer.
! If the module is a Python module (as opposed to a builtin module or
an dynamically loaded extension), it should execute the module's
code in the module's global name space (module.__dict__).
--- 264,271 ----
- It should add an __importer__ attribute to the module, set to the
loader object. This is mostly for introspection, but can be used
! for importer-specific extras, for example getting data associated
with an importer.
! If the module is a Python module (as opposed to a built-in module or
an dynamically loaded extension), it should execute the module's
code in the module's global name space (module.__dict__).
***************
*** 289,293 ****
Meta hooks are called at the start of import processing, before any
other import processing (so that meta hooks can override sys.path
! processing, or frozen modules, or even builtin modules). To
register a meta hook, simply add the importer object to
sys.meta_path (the list of registered meta hooks).
--- 290,294 ----
Meta hooks are called at the start of import processing, before any
other import processing (so that meta hooks can override sys.path
! processing, or frozen modules, or even built-in modules). To
register a meta hook, simply add the importer object to
sys.meta_path (the list of registered meta hooks).
***************
*** 342,346 ****
as path items are also allowed (yet, are discouraged for the same
reasons as they are discouraged on sys.path, at least for general
! purpose code). Meta importers don't neccesarily use sys.path at all
to do their work and therefore may also ignore the value of
pkg.__path__. In this case it is still advised to set it to list,
--- 343,347 ----
as path items are also allowed (yet, are discouraged for the same
reasons as they are discouraged on sys.path, at least for general
! purpose code). Meta importers don't necessarily use sys.path at all
to do their work and therefore may also ignore the value of
pkg.__path__. In this case it is still advised to set it to list,
***************
*** 355,360 ****
simply add a new function to the imp module. The meaning of the
existing imp.find_module() and imp.load_module() calls changes from:
! "they expose the builtin import mechanism" to "they expose the basic
! *unhooked* builtin import mechanism". They simply won't invoke any
import hooks. A new imp module function is proposed under the name
"find_module2", with is used like the following pattern:
--- 356,361 ----
simply add a new function to the imp module. The meaning of the
existing imp.find_module() and imp.load_module() calls changes from:
! "they expose the built-in import mechanism" to "they expose the basic
! *unhooked* built-in import mechanism". They simply won't invoke any
import hooks. A new imp module function is proposed under the name
"find_module2", with is used like the following pattern:
***************
*** 405,409 ****
os.path.join(sys.prefix, "data", package_name).
! - Import hooks could offer a standard way of getting at datafiles
relative to the module file. The standard zipimport object
provides a method get_data(name) which returns the content of the
--- 406,410 ----
os.path.join(sys.prefix, "data", package_name).
! - Import hooks could offer a standard way of getting at data files
relative to the module file. The standard zipimport object
provides a method get_data(name) which returns the content of the