| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
This should make the Linux distros happy as it is now easier to leave
importlib's tests out of their base Python distribution.
|
|
|
|
|
|
|
| |
statement (e.g. ``from distutils import msvc9compiler``) that triggers
an ImportError of its own (e.g. the non-existence of winreg), let that
exception propagate instead of raising a generic ImportError for the
module being requested (e.g. msvc9compiler).
|
| |
|
|
|
|
| |
just assertTrue.
|
|
|
|
| |
import one of its modules then raise an error.
|
|
|
|
| |
finder instead of using some (now non-existent) implicit finder.
|
|
|
|
| |
ImportWarning is raised if sys.meta_path is found to be empty.
|
|
|
|
|
|
|
|
|
|
|
|
| |
be implicit.
Added a warning for when sys.path_hooks is found to be empty. Also
changed the meaning of None in sys.path_importer_cache to represent
trying sys.path_hooks again (an interpretation of previous semantics).
Also added a warning for when None was found.
The long-term goal is for None in sys.path_importer_cache to represent
the same as imp.NullImporter: no finder found for that sys.path entry.
|
|
|
|
|
| |
Being able to overload a sys.module entry during import of a module was broken
by this changeset.
|
|
|
|
|
|
|
| |
in importlib.
Thanks to PJE for pointing out the issue and Nick Coghlan for filing
the bug.
|
|
|
|
|
|
| |
or __name__ are not set in globals.
Thanks to Stefan Behnel for the bug report.
|
|
|
|
|
|
|
|
|
|
|
|
| |
of sys.modules when possible.
This is being done for two reasons. One is to gain a little bit of
performance by skipping an unnecessary dict lookup in sys.modules. But
the other (and main) reason is to be a little bit more clear in how
things should work from the perspective of import's interactions with
loaders. Otherwise loaders can easily forget to return the module even
though PEP 302 explicitly states they are expected to return the module
they loaded.
|
|
|
|
|
| |
__import__('mod', {'__packaging__': 'pkg', level=1) w/o properly (and
thus not segfaulting).
|
|
|
|
|
|
|
| |
importlib._bootstrap is now frozen into Python/importlib.h and stored
as _frozen_importlib in sys.modules. Py_Initialize() loads the frozen
code along with sys and imp and then uses _frozen_importlib._install()
to set builtins.__import__() w/ _frozen_importlib.__import__().
|
|
|
|
| |
attributes.
|
|
|
|
| |
after itself properly.
|
|
|
|
|
|
|
|
| |
importation, then respect that injection.
Discovered thanks to Lib/xml/parsers/expat.py injecting
xml.parsers.expat.errors and etree now importing that directly as a
module.
|
| |
|
|
|
|
|
|
| |
importlib.invalidate_caches() function.
importlib is now often faster than imp.find_module() at finding modules.
|
|
|
|
|
|
|
| |
It seems better to cache the finder for the cwd under its full path
insetad of '' in case the cwd changes. Otherwise FileFinder needs to
dynamically change itself based on whether it is given '' instead of
caching a finder for every change to the cwd.
|
|
|
|
|
| |
This is to bring it more in line with what PEP 328 set out to do with
removing ambiguous absolute/relative import semantics.
|
|
|
|
|
| |
__file__ being an absolute path when the module is found in the
current directory.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This required moving the class from importlib/abc.py into
importlib/_bootstrap.py and jiggering some code to work better with the class.
This included changing how the file finder worked to better meet import
semantics. This also led to fixing importlib to handle the empty string from
sys.path as import currently does (and making me wish we didn't support that
instead just required people to insert '.' instead to represent cwd).
It also required making the new set_data abstractmethod create
any needed subdirectories implicitly thanks to __pycache__ (it was either this
or grow the SourceLoader ABC to gain an 'exists' method and either a mkdir
method or have set_data with no data arg mean to create a directory).
Lastly, as an optimization the file loaders cache the file path where the
finder found something to use for loading (this is thanks to having a
sourceless loader separate from the source loader to simplify the code and
cut out stat calls).
Unfortunately test_runpy assumed a loader would always work for a module, even
if you changed from underneath it what it was expected to work with. By simply
dropping the previous loader in test_runpy so the proper loader can be returned
by the finder fixed the failure.
At this point importlib deviates from import on two points:
1. The exception raised when trying to import a file is different (import does
an explicit file check to print a special message, importlib just says the path
cannot be imported as if it was just some module name).
2. the co_filename on a code object is not being set to where bytecode was
actually loaded from instead of where the marshalled code object originally
came from (a solution for this has already been agreed upon on python-dev but has
not been implemented yet; issue8611).
|
|
|
|
|
|
| |
AttributeError in importlib when it should be an ImportError.
Found when running importlib against test_runpy.
|
|
|
|
|
|
|
|
| |
__package__, it was used. This was incorrect since it could be set to None to
represent the fact that a proper value was unknown. Now None will trigger the
calculation for __package__.
Discovered when running importlib against test_importhooks.
|
|
|
|
|
|
|
|
| |
attribute. Was throwing AttributeError before. Discovered when running
test_builtin against importlib.
This exception change is specific to importlib.__import__() and does not apply to
import_module() as it is being done for compatibility reasons only.
|
|
|
|
| |
variable as it might change later.
|
| |
|
|
|
|
| |
running importlib against test___all__.
|
|
|
|
| |
current import semantics.
|
|
|
|
|
| |
Obviously one shouldn't do whole sale conversions like this, but I was already
going through the test code and I was bored at the airport.
|
|
|
|
| |
assertRaises context manager.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
entries in sys.path_importer_cache. While this differs from semantics in how
__import__ works, it prevents any implicit semantics from taking hold with
users.
|
| |
|
| |
|
|
|
|
|
|
|
| |
+ Ditch using arguments to super().
+ Ditch subclassing from object directly.
+ Move directory check out of chaining path hook to file path hook/finder.
+ Rename some classes to better reflect they are finders, not importers.
|
|
|
|
| |
not handled by importlib._bootstrap._DefaultPathFinder).
|
|
|
|
|
|
|
|
|
| |
and relies much more on meta path finders to abstract out various parts of
import.
As part of this the semantics for import_module tightened up and now follow
__import__ much more closely (biggest thing is that the 'package' argument must
now already be imported, else a SystemError is raised).
|
|
|
|
| |
implicit hooks are handled properly.
|
| |
|
|
|
|
| |
importlib.machinery.PathFinder.
|
| |
|
| |
|
| |
|
|
planned for the package.
There are no docs yet, but they are coming once the API for the first new
function, importlib.import_module() is finalized.
|