mercurial: implement import hook for handling C/Python modules
There are a handful of modules that have both pure Python and C
extension implementations. Currently, setup.py copies files from
mercurial/pure/*.py to mercurial/ during the install process if C
extensions are not available. This way, "import mercurial.X" will
work whether C extensions are available or not.
This approach has a few drawbacks. First, there aren't run-time checks
verifying the C extensions are loaded when they should be. This could
lead to accidental use of the slower pure Python modules. Second, the
C extensions aren't compatible with PyPy and running Mercurial with
PyPy requires installing Mercurial - you can't run ./hg from a source
checkout. This makes developing while running PyPy somewhat difficult.
This patch implements a PEP-302 import hook for finding and loading the
modules with both C and Python implementations. When a module with dual
implementations is requested for import, its import is handled by our
import hook.
The importer has a mechanism that controls what types of modules we
allow to load. We call this loading behavior the "module load policy."
There are 3 settings:
* Only load C extensions
* Only load pure Python
* Try to load C and fall back to Python
An environment variable allows overriding this policy at run time. This
is mainly useful for developers and for performing actions against the
source checkout (such as installing), which require overriding the
default (strict) policy about requiring C extensions.
The default mode for now is to allow both. This isn't proper and is
technically backwards incompatible. However, it is necessary to
implement a sane patch series that doesn't break the world during
future bisections. The behavior will be corrected in future patch.
We choose the main mercurial/__init__.py module for this code out of
necessity: in a future world, if the custom module importer isn't
registered, we'll fail to find/import certain modules when running
from a pure installation. Without the magical import-time side-effects,
*any* importer of mercurial.* modules would be required to call a
function to register our importer. I'm not a fan of import time side
effects and I initially attempted to do this. However, I was foiled by
our own test harness, which has numerous `python` invoked scripts that
"import mercurial" and fail because the importer isn't registered.
Realizing this problem is probably present in random Python scripts
that have been written over the years, I decided that sacrificing
purity for backwards compatibility is necessary. Plus, if you are
programming Python, "import" should probably "just work."
It's worth noting that now that we have a custom module loader, it
would be possible to hook up demand module proxies at this level
instead of replacing __import__. We leave this work for another time,
if it's even desired.
This patch breaks importing in environments where Mercurial modules
are loaded from a zip file (such as py2exe distributions). This will
be addressed in a subsequent patch.
2015-12-04 08:37:01 +03:00
|
|
|
# __init__.py - Startup and module loading logic for Mercurial.
|
|
|
|
#
|
|
|
|
# Copyright 2015 Gregory Szorc <gregory.szorc@gmail.com>
|
|
|
|
#
|
|
|
|
# This software may be used and distributed according to the terms of the
|
|
|
|
# GNU General Public License version 2 or any later version.
|
|
|
|
|
|
|
|
from __future__ import absolute_import
|
|
|
|
|
|
|
|
import imp
|
|
|
|
import os
|
|
|
|
import sys
|
mercurial: support loading modules from zipimporter
The previous refactor to module importing broke module loading when
mercurial.* modules were loaded from a zipfile (using a zipimporter).
This scenario is likely encountered when using py2exe.
Supporting zipimporter and the traditional importer side-by-side
turns out to be quite a pain. In Python 2.x, the standard, file-based
import mechanism is partially implemented in C. The sys.meta_path
and sys.path_hooks hook points exist to allow custom importers in
Python/userland. zipimport.zipimporter and our "hgimporter" class
from earlier in this patch series are 2 of these.
In a standard Python installation (no matter if running in py2exe
or similar or not), zipimport.zipimporter appears to be registered
in sys.path_hooks. This means that as each sys.path entry is
consulted, it will ask zipimporter if it supports that path and
zipimporter will be used if that entry is a zip file. In a
py2exe environment, sys.path contains an entry with the path to
the zip file containing the Python standard library along with
Mercurial's Python files.
The way the importer mechanism works is the first importer that
declares knowledge of a module (via find_module() returning an
object) gets to load it. Since our "hgimporter" is registered
in sys.meta_path and returns an interest in specific mercurial.*
modules, the zipimporter registered on sys.path_hooks never comes
into play for these modules. So, we need to be zipimporter aware
and call into zipimporter to load modules.
This patch teaches "hgimporter" how to call out into zipimporter
when necessary. We detect the necessity of zipimporter by looking
at the loader for the "mercurial" module. If it is a zipimporter
instance, we load via zipimporter.
The behavior of zipimporter is a bit wonky.
You appear to need separate zipimporter instances for each directory
in the zip file. I'm not sure why this is. I suspect it has
something to do with the low-level importing mechanism (implemented
in C) operating on a per-directory basis. PEP-302 makes some
references to this. I was not able to get a zipimporter to
import modules outside of its immediate directory no matter how
I specified the module name. This is why we use separate
zipimporter instances for the ".zip/mercurial" and
".zip/mercurial/pure" locations.
The zipimporter documentation for Python 2.7 explicitly states that
zipimporter does not import dynamic modules (C extensions). Yet from
a py2exe distribution on Windows - where the .pyd files are *not*
in the zip archive - zipimporter imported these dynamic modules
just fine! I'm not sure if dynamic modules can't be imported from
*inside* the zip archive or whether zipimporter looks for dynamic
modules outside the zip archive. All I know is zipimporter does
manage to import the .pyd files on Windows and this patch makes
our new importer compatible with py2exe.
In the ideal world, We'd probably reimplement or fall back to parts
of the built-in import mechanism instead of handling zipimporter
specially. After all, if we're loading Mercurial modules via
something that isn't the built-in file-based importer or zipimporter,
our custom importer will likely fail because it doesn't know how to
call into it. I'd like to think that we'll never encounter this
in the wild, but you never know. If we do encounter it, we can
come up with another solution.
It's worth nothing that Python 3 has moved a lot of the importing
code from C to Python. Python 3 gives you near total control over
the import mechanism. So in the very distant future when Mercurial
drops Python 2 support, it's likely that our custom importer code
can be refactored to something a bit saner.
2015-12-04 08:25:05 +03:00
|
|
|
import zipimport
|
mercurial: implement import hook for handling C/Python modules
There are a handful of modules that have both pure Python and C
extension implementations. Currently, setup.py copies files from
mercurial/pure/*.py to mercurial/ during the install process if C
extensions are not available. This way, "import mercurial.X" will
work whether C extensions are available or not.
This approach has a few drawbacks. First, there aren't run-time checks
verifying the C extensions are loaded when they should be. This could
lead to accidental use of the slower pure Python modules. Second, the
C extensions aren't compatible with PyPy and running Mercurial with
PyPy requires installing Mercurial - you can't run ./hg from a source
checkout. This makes developing while running PyPy somewhat difficult.
This patch implements a PEP-302 import hook for finding and loading the
modules with both C and Python implementations. When a module with dual
implementations is requested for import, its import is handled by our
import hook.
The importer has a mechanism that controls what types of modules we
allow to load. We call this loading behavior the "module load policy."
There are 3 settings:
* Only load C extensions
* Only load pure Python
* Try to load C and fall back to Python
An environment variable allows overriding this policy at run time. This
is mainly useful for developers and for performing actions against the
source checkout (such as installing), which require overriding the
default (strict) policy about requiring C extensions.
The default mode for now is to allow both. This isn't proper and is
technically backwards incompatible. However, it is necessary to
implement a sane patch series that doesn't break the world during
future bisections. The behavior will be corrected in future patch.
We choose the main mercurial/__init__.py module for this code out of
necessity: in a future world, if the custom module importer isn't
registered, we'll fail to find/import certain modules when running
from a pure installation. Without the magical import-time side-effects,
*any* importer of mercurial.* modules would be required to call a
function to register our importer. I'm not a fan of import time side
effects and I initially attempted to do this. However, I was foiled by
our own test harness, which has numerous `python` invoked scripts that
"import mercurial" and fail because the importer isn't registered.
Realizing this problem is probably present in random Python scripts
that have been written over the years, I decided that sacrificing
purity for backwards compatibility is necessary. Plus, if you are
programming Python, "import" should probably "just work."
It's worth noting that now that we have a custom module loader, it
would be possible to hook up demand module proxies at this level
instead of replacing __import__. We leave this work for another time,
if it's even desired.
This patch breaks importing in environments where Mercurial modules
are loaded from a zip file (such as py2exe distributions). This will
be addressed in a subsequent patch.
2015-12-04 08:37:01 +03:00
|
|
|
|
2016-03-09 22:55:45 +03:00
|
|
|
from . import (
|
|
|
|
policy
|
|
|
|
)
|
mercurial: implement import hook for handling C/Python modules
There are a handful of modules that have both pure Python and C
extension implementations. Currently, setup.py copies files from
mercurial/pure/*.py to mercurial/ during the install process if C
extensions are not available. This way, "import mercurial.X" will
work whether C extensions are available or not.
This approach has a few drawbacks. First, there aren't run-time checks
verifying the C extensions are loaded when they should be. This could
lead to accidental use of the slower pure Python modules. Second, the
C extensions aren't compatible with PyPy and running Mercurial with
PyPy requires installing Mercurial - you can't run ./hg from a source
checkout. This makes developing while running PyPy somewhat difficult.
This patch implements a PEP-302 import hook for finding and loading the
modules with both C and Python implementations. When a module with dual
implementations is requested for import, its import is handled by our
import hook.
The importer has a mechanism that controls what types of modules we
allow to load. We call this loading behavior the "module load policy."
There are 3 settings:
* Only load C extensions
* Only load pure Python
* Try to load C and fall back to Python
An environment variable allows overriding this policy at run time. This
is mainly useful for developers and for performing actions against the
source checkout (such as installing), which require overriding the
default (strict) policy about requiring C extensions.
The default mode for now is to allow both. This isn't proper and is
technically backwards incompatible. However, it is necessary to
implement a sane patch series that doesn't break the world during
future bisections. The behavior will be corrected in future patch.
We choose the main mercurial/__init__.py module for this code out of
necessity: in a future world, if the custom module importer isn't
registered, we'll fail to find/import certain modules when running
from a pure installation. Without the magical import-time side-effects,
*any* importer of mercurial.* modules would be required to call a
function to register our importer. I'm not a fan of import time side
effects and I initially attempted to do this. However, I was foiled by
our own test harness, which has numerous `python` invoked scripts that
"import mercurial" and fail because the importer isn't registered.
Realizing this problem is probably present in random Python scripts
that have been written over the years, I decided that sacrificing
purity for backwards compatibility is necessary. Plus, if you are
programming Python, "import" should probably "just work."
It's worth noting that now that we have a custom module loader, it
would be possible to hook up demand module proxies at this level
instead of replacing __import__. We leave this work for another time,
if it's even desired.
This patch breaks importing in environments where Mercurial modules
are loaded from a zip file (such as py2exe distributions). This will
be addressed in a subsequent patch.
2015-12-04 08:37:01 +03:00
|
|
|
|
2016-03-09 22:55:45 +03:00
|
|
|
__all__ = []
|
2016-03-13 00:19:19 +03:00
|
|
|
|
2016-03-09 22:55:45 +03:00
|
|
|
modulepolicy = policy.policy
|
mercurial: implement import hook for handling C/Python modules
There are a handful of modules that have both pure Python and C
extension implementations. Currently, setup.py copies files from
mercurial/pure/*.py to mercurial/ during the install process if C
extensions are not available. This way, "import mercurial.X" will
work whether C extensions are available or not.
This approach has a few drawbacks. First, there aren't run-time checks
verifying the C extensions are loaded when they should be. This could
lead to accidental use of the slower pure Python modules. Second, the
C extensions aren't compatible with PyPy and running Mercurial with
PyPy requires installing Mercurial - you can't run ./hg from a source
checkout. This makes developing while running PyPy somewhat difficult.
This patch implements a PEP-302 import hook for finding and loading the
modules with both C and Python implementations. When a module with dual
implementations is requested for import, its import is handled by our
import hook.
The importer has a mechanism that controls what types of modules we
allow to load. We call this loading behavior the "module load policy."
There are 3 settings:
* Only load C extensions
* Only load pure Python
* Try to load C and fall back to Python
An environment variable allows overriding this policy at run time. This
is mainly useful for developers and for performing actions against the
source checkout (such as installing), which require overriding the
default (strict) policy about requiring C extensions.
The default mode for now is to allow both. This isn't proper and is
technically backwards incompatible. However, it is necessary to
implement a sane patch series that doesn't break the world during
future bisections. The behavior will be corrected in future patch.
We choose the main mercurial/__init__.py module for this code out of
necessity: in a future world, if the custom module importer isn't
registered, we'll fail to find/import certain modules when running
from a pure installation. Without the magical import-time side-effects,
*any* importer of mercurial.* modules would be required to call a
function to register our importer. I'm not a fan of import time side
effects and I initially attempted to do this. However, I was foiled by
our own test harness, which has numerous `python` invoked scripts that
"import mercurial" and fail because the importer isn't registered.
Realizing this problem is probably present in random Python scripts
that have been written over the years, I decided that sacrificing
purity for backwards compatibility is necessary. Plus, if you are
programming Python, "import" should probably "just work."
It's worth noting that now that we have a custom module loader, it
would be possible to hook up demand module proxies at this level
instead of replacing __import__. We leave this work for another time,
if it's even desired.
This patch breaks importing in environments where Mercurial modules
are loaded from a zip file (such as py2exe distributions). This will
be addressed in a subsequent patch.
2015-12-04 08:37:01 +03:00
|
|
|
|
|
|
|
# Modules that have both Python and C implementations. See also the
|
|
|
|
# set of .py files under mercurial/pure/.
|
|
|
|
_dualmodules = set([
|
|
|
|
'mercurial.base85',
|
|
|
|
'mercurial.bdiff',
|
|
|
|
'mercurial.diffhelpers',
|
|
|
|
'mercurial.mpatch',
|
|
|
|
'mercurial.osutil',
|
|
|
|
'mercurial.parsers',
|
|
|
|
])
|
|
|
|
|
|
|
|
class hgimporter(object):
|
|
|
|
"""Object that conforms to import hook interface defined in PEP-302."""
|
|
|
|
def find_module(self, name, path=None):
|
|
|
|
# We only care about modules that have both C and pure implementations.
|
|
|
|
if name in _dualmodules:
|
|
|
|
return self
|
|
|
|
return None
|
|
|
|
|
|
|
|
def load_module(self, name):
|
|
|
|
mod = sys.modules.get(name, None)
|
|
|
|
if mod:
|
|
|
|
return mod
|
|
|
|
|
|
|
|
mercurial = sys.modules['mercurial']
|
|
|
|
|
mercurial: support loading modules from zipimporter
The previous refactor to module importing broke module loading when
mercurial.* modules were loaded from a zipfile (using a zipimporter).
This scenario is likely encountered when using py2exe.
Supporting zipimporter and the traditional importer side-by-side
turns out to be quite a pain. In Python 2.x, the standard, file-based
import mechanism is partially implemented in C. The sys.meta_path
and sys.path_hooks hook points exist to allow custom importers in
Python/userland. zipimport.zipimporter and our "hgimporter" class
from earlier in this patch series are 2 of these.
In a standard Python installation (no matter if running in py2exe
or similar or not), zipimport.zipimporter appears to be registered
in sys.path_hooks. This means that as each sys.path entry is
consulted, it will ask zipimporter if it supports that path and
zipimporter will be used if that entry is a zip file. In a
py2exe environment, sys.path contains an entry with the path to
the zip file containing the Python standard library along with
Mercurial's Python files.
The way the importer mechanism works is the first importer that
declares knowledge of a module (via find_module() returning an
object) gets to load it. Since our "hgimporter" is registered
in sys.meta_path and returns an interest in specific mercurial.*
modules, the zipimporter registered on sys.path_hooks never comes
into play for these modules. So, we need to be zipimporter aware
and call into zipimporter to load modules.
This patch teaches "hgimporter" how to call out into zipimporter
when necessary. We detect the necessity of zipimporter by looking
at the loader for the "mercurial" module. If it is a zipimporter
instance, we load via zipimporter.
The behavior of zipimporter is a bit wonky.
You appear to need separate zipimporter instances for each directory
in the zip file. I'm not sure why this is. I suspect it has
something to do with the low-level importing mechanism (implemented
in C) operating on a per-directory basis. PEP-302 makes some
references to this. I was not able to get a zipimporter to
import modules outside of its immediate directory no matter how
I specified the module name. This is why we use separate
zipimporter instances for the ".zip/mercurial" and
".zip/mercurial/pure" locations.
The zipimporter documentation for Python 2.7 explicitly states that
zipimporter does not import dynamic modules (C extensions). Yet from
a py2exe distribution on Windows - where the .pyd files are *not*
in the zip archive - zipimporter imported these dynamic modules
just fine! I'm not sure if dynamic modules can't be imported from
*inside* the zip archive or whether zipimporter looks for dynamic
modules outside the zip archive. All I know is zipimporter does
manage to import the .pyd files on Windows and this patch makes
our new importer compatible with py2exe.
In the ideal world, We'd probably reimplement or fall back to parts
of the built-in import mechanism instead of handling zipimporter
specially. After all, if we're loading Mercurial modules via
something that isn't the built-in file-based importer or zipimporter,
our custom importer will likely fail because it doesn't know how to
call into it. I'd like to think that we'll never encounter this
in the wild, but you never know. If we do encounter it, we can
come up with another solution.
It's worth nothing that Python 3 has moved a lot of the importing
code from C to Python. Python 3 gives you near total control over
the import mechanism. So in the very distant future when Mercurial
drops Python 2 support, it's likely that our custom importer code
can be refactored to something a bit saner.
2015-12-04 08:25:05 +03:00
|
|
|
# The zip importer behaves sufficiently differently from the default
|
|
|
|
# importer to warrant its own code path.
|
|
|
|
loader = getattr(mercurial, '__loader__', None)
|
|
|
|
if isinstance(loader, zipimport.zipimporter):
|
|
|
|
def ziploader(*paths):
|
|
|
|
"""Obtain a zipimporter for a directory under the main zip."""
|
|
|
|
path = os.path.join(loader.archive, *paths)
|
|
|
|
zl = sys.path_importer_cache.get(path)
|
|
|
|
if not zl:
|
|
|
|
zl = zipimport.zipimporter(path)
|
|
|
|
return zl
|
|
|
|
|
|
|
|
try:
|
2016-06-07 16:35:58 +03:00
|
|
|
if modulepolicy in policy.policynoc:
|
mercurial: support loading modules from zipimporter
The previous refactor to module importing broke module loading when
mercurial.* modules were loaded from a zipfile (using a zipimporter).
This scenario is likely encountered when using py2exe.
Supporting zipimporter and the traditional importer side-by-side
turns out to be quite a pain. In Python 2.x, the standard, file-based
import mechanism is partially implemented in C. The sys.meta_path
and sys.path_hooks hook points exist to allow custom importers in
Python/userland. zipimport.zipimporter and our "hgimporter" class
from earlier in this patch series are 2 of these.
In a standard Python installation (no matter if running in py2exe
or similar or not), zipimport.zipimporter appears to be registered
in sys.path_hooks. This means that as each sys.path entry is
consulted, it will ask zipimporter if it supports that path and
zipimporter will be used if that entry is a zip file. In a
py2exe environment, sys.path contains an entry with the path to
the zip file containing the Python standard library along with
Mercurial's Python files.
The way the importer mechanism works is the first importer that
declares knowledge of a module (via find_module() returning an
object) gets to load it. Since our "hgimporter" is registered
in sys.meta_path and returns an interest in specific mercurial.*
modules, the zipimporter registered on sys.path_hooks never comes
into play for these modules. So, we need to be zipimporter aware
and call into zipimporter to load modules.
This patch teaches "hgimporter" how to call out into zipimporter
when necessary. We detect the necessity of zipimporter by looking
at the loader for the "mercurial" module. If it is a zipimporter
instance, we load via zipimporter.
The behavior of zipimporter is a bit wonky.
You appear to need separate zipimporter instances for each directory
in the zip file. I'm not sure why this is. I suspect it has
something to do with the low-level importing mechanism (implemented
in C) operating on a per-directory basis. PEP-302 makes some
references to this. I was not able to get a zipimporter to
import modules outside of its immediate directory no matter how
I specified the module name. This is why we use separate
zipimporter instances for the ".zip/mercurial" and
".zip/mercurial/pure" locations.
The zipimporter documentation for Python 2.7 explicitly states that
zipimporter does not import dynamic modules (C extensions). Yet from
a py2exe distribution on Windows - where the .pyd files are *not*
in the zip archive - zipimporter imported these dynamic modules
just fine! I'm not sure if dynamic modules can't be imported from
*inside* the zip archive or whether zipimporter looks for dynamic
modules outside the zip archive. All I know is zipimporter does
manage to import the .pyd files on Windows and this patch makes
our new importer compatible with py2exe.
In the ideal world, We'd probably reimplement or fall back to parts
of the built-in import mechanism instead of handling zipimporter
specially. After all, if we're loading Mercurial modules via
something that isn't the built-in file-based importer or zipimporter,
our custom importer will likely fail because it doesn't know how to
call into it. I'd like to think that we'll never encounter this
in the wild, but you never know. If we do encounter it, we can
come up with another solution.
It's worth nothing that Python 3 has moved a lot of the importing
code from C to Python. Python 3 gives you near total control over
the import mechanism. So in the very distant future when Mercurial
drops Python 2 support, it's likely that our custom importer code
can be refactored to something a bit saner.
2015-12-04 08:25:05 +03:00
|
|
|
raise ImportError()
|
|
|
|
|
|
|
|
zl = ziploader('mercurial')
|
|
|
|
mod = zl.load_module(name)
|
|
|
|
# Unlike imp, ziploader doesn't expose module metadata that
|
|
|
|
# indicates the type of module. So just assume what we found
|
|
|
|
# is OK (even though it could be a pure Python module).
|
|
|
|
except ImportError:
|
|
|
|
if modulepolicy == 'c':
|
|
|
|
raise
|
|
|
|
zl = ziploader('mercurial', 'pure')
|
|
|
|
mod = zl.load_module(name)
|
|
|
|
|
|
|
|
sys.modules[name] = mod
|
|
|
|
return mod
|
|
|
|
|
mercurial: implement import hook for handling C/Python modules
There are a handful of modules that have both pure Python and C
extension implementations. Currently, setup.py copies files from
mercurial/pure/*.py to mercurial/ during the install process if C
extensions are not available. This way, "import mercurial.X" will
work whether C extensions are available or not.
This approach has a few drawbacks. First, there aren't run-time checks
verifying the C extensions are loaded when they should be. This could
lead to accidental use of the slower pure Python modules. Second, the
C extensions aren't compatible with PyPy and running Mercurial with
PyPy requires installing Mercurial - you can't run ./hg from a source
checkout. This makes developing while running PyPy somewhat difficult.
This patch implements a PEP-302 import hook for finding and loading the
modules with both C and Python implementations. When a module with dual
implementations is requested for import, its import is handled by our
import hook.
The importer has a mechanism that controls what types of modules we
allow to load. We call this loading behavior the "module load policy."
There are 3 settings:
* Only load C extensions
* Only load pure Python
* Try to load C and fall back to Python
An environment variable allows overriding this policy at run time. This
is mainly useful for developers and for performing actions against the
source checkout (such as installing), which require overriding the
default (strict) policy about requiring C extensions.
The default mode for now is to allow both. This isn't proper and is
technically backwards incompatible. However, it is necessary to
implement a sane patch series that doesn't break the world during
future bisections. The behavior will be corrected in future patch.
We choose the main mercurial/__init__.py module for this code out of
necessity: in a future world, if the custom module importer isn't
registered, we'll fail to find/import certain modules when running
from a pure installation. Without the magical import-time side-effects,
*any* importer of mercurial.* modules would be required to call a
function to register our importer. I'm not a fan of import time side
effects and I initially attempted to do this. However, I was foiled by
our own test harness, which has numerous `python` invoked scripts that
"import mercurial" and fail because the importer isn't registered.
Realizing this problem is probably present in random Python scripts
that have been written over the years, I decided that sacrificing
purity for backwards compatibility is necessary. Plus, if you are
programming Python, "import" should probably "just work."
It's worth noting that now that we have a custom module loader, it
would be possible to hook up demand module proxies at this level
instead of replacing __import__. We leave this work for another time,
if it's even desired.
This patch breaks importing in environments where Mercurial modules
are loaded from a zip file (such as py2exe distributions). This will
be addressed in a subsequent patch.
2015-12-04 08:37:01 +03:00
|
|
|
# Unlike the default importer which searches special locations and
|
|
|
|
# sys.path, we only look in the directory where "mercurial" was
|
|
|
|
# imported from.
|
|
|
|
|
|
|
|
# imp.find_module doesn't support submodules (modules with ".").
|
|
|
|
# Instead you have to pass the parent package's __path__ attribute
|
|
|
|
# as the path argument.
|
|
|
|
stem = name.split('.')[-1]
|
|
|
|
|
|
|
|
try:
|
2016-06-07 16:35:58 +03:00
|
|
|
if modulepolicy in policy.policynoc:
|
mercurial: implement import hook for handling C/Python modules
There are a handful of modules that have both pure Python and C
extension implementations. Currently, setup.py copies files from
mercurial/pure/*.py to mercurial/ during the install process if C
extensions are not available. This way, "import mercurial.X" will
work whether C extensions are available or not.
This approach has a few drawbacks. First, there aren't run-time checks
verifying the C extensions are loaded when they should be. This could
lead to accidental use of the slower pure Python modules. Second, the
C extensions aren't compatible with PyPy and running Mercurial with
PyPy requires installing Mercurial - you can't run ./hg from a source
checkout. This makes developing while running PyPy somewhat difficult.
This patch implements a PEP-302 import hook for finding and loading the
modules with both C and Python implementations. When a module with dual
implementations is requested for import, its import is handled by our
import hook.
The importer has a mechanism that controls what types of modules we
allow to load. We call this loading behavior the "module load policy."
There are 3 settings:
* Only load C extensions
* Only load pure Python
* Try to load C and fall back to Python
An environment variable allows overriding this policy at run time. This
is mainly useful for developers and for performing actions against the
source checkout (such as installing), which require overriding the
default (strict) policy about requiring C extensions.
The default mode for now is to allow both. This isn't proper and is
technically backwards incompatible. However, it is necessary to
implement a sane patch series that doesn't break the world during
future bisections. The behavior will be corrected in future patch.
We choose the main mercurial/__init__.py module for this code out of
necessity: in a future world, if the custom module importer isn't
registered, we'll fail to find/import certain modules when running
from a pure installation. Without the magical import-time side-effects,
*any* importer of mercurial.* modules would be required to call a
function to register our importer. I'm not a fan of import time side
effects and I initially attempted to do this. However, I was foiled by
our own test harness, which has numerous `python` invoked scripts that
"import mercurial" and fail because the importer isn't registered.
Realizing this problem is probably present in random Python scripts
that have been written over the years, I decided that sacrificing
purity for backwards compatibility is necessary. Plus, if you are
programming Python, "import" should probably "just work."
It's worth noting that now that we have a custom module loader, it
would be possible to hook up demand module proxies at this level
instead of replacing __import__. We leave this work for another time,
if it's even desired.
This patch breaks importing in environments where Mercurial modules
are loaded from a zip file (such as py2exe distributions). This will
be addressed in a subsequent patch.
2015-12-04 08:37:01 +03:00
|
|
|
raise ImportError()
|
|
|
|
|
|
|
|
modinfo = imp.find_module(stem, mercurial.__path__)
|
|
|
|
|
|
|
|
# The Mercurial installer used to copy files from
|
|
|
|
# mercurial/pure/*.py to mercurial/*.py. Therefore, it's possible
|
|
|
|
# for some installations to have .py files under mercurial/*.
|
|
|
|
# Loading Python modules when we expected C versions could result
|
|
|
|
# in a) poor performance b) loading a version from a previous
|
|
|
|
# Mercurial version, potentially leading to incompatibility. Either
|
|
|
|
# scenario is bad. So we verify that modules loaded from
|
|
|
|
# mercurial/* are C extensions. If the current policy allows the
|
|
|
|
# loading of .py modules, the module will be re-imported from
|
|
|
|
# mercurial/pure/* below.
|
2015-11-25 09:50:04 +03:00
|
|
|
if modinfo[2][2] != imp.C_EXTENSION:
|
|
|
|
raise ImportError('.py version of %s found where C '
|
|
|
|
'version should exist' % name)
|
mercurial: implement import hook for handling C/Python modules
There are a handful of modules that have both pure Python and C
extension implementations. Currently, setup.py copies files from
mercurial/pure/*.py to mercurial/ during the install process if C
extensions are not available. This way, "import mercurial.X" will
work whether C extensions are available or not.
This approach has a few drawbacks. First, there aren't run-time checks
verifying the C extensions are loaded when they should be. This could
lead to accidental use of the slower pure Python modules. Second, the
C extensions aren't compatible with PyPy and running Mercurial with
PyPy requires installing Mercurial - you can't run ./hg from a source
checkout. This makes developing while running PyPy somewhat difficult.
This patch implements a PEP-302 import hook for finding and loading the
modules with both C and Python implementations. When a module with dual
implementations is requested for import, its import is handled by our
import hook.
The importer has a mechanism that controls what types of modules we
allow to load. We call this loading behavior the "module load policy."
There are 3 settings:
* Only load C extensions
* Only load pure Python
* Try to load C and fall back to Python
An environment variable allows overriding this policy at run time. This
is mainly useful for developers and for performing actions against the
source checkout (such as installing), which require overriding the
default (strict) policy about requiring C extensions.
The default mode for now is to allow both. This isn't proper and is
technically backwards incompatible. However, it is necessary to
implement a sane patch series that doesn't break the world during
future bisections. The behavior will be corrected in future patch.
We choose the main mercurial/__init__.py module for this code out of
necessity: in a future world, if the custom module importer isn't
registered, we'll fail to find/import certain modules when running
from a pure installation. Without the magical import-time side-effects,
*any* importer of mercurial.* modules would be required to call a
function to register our importer. I'm not a fan of import time side
effects and I initially attempted to do this. However, I was foiled by
our own test harness, which has numerous `python` invoked scripts that
"import mercurial" and fail because the importer isn't registered.
Realizing this problem is probably present in random Python scripts
that have been written over the years, I decided that sacrificing
purity for backwards compatibility is necessary. Plus, if you are
programming Python, "import" should probably "just work."
It's worth noting that now that we have a custom module loader, it
would be possible to hook up demand module proxies at this level
instead of replacing __import__. We leave this work for another time,
if it's even desired.
This patch breaks importing in environments where Mercurial modules
are loaded from a zip file (such as py2exe distributions). This will
be addressed in a subsequent patch.
2015-12-04 08:37:01 +03:00
|
|
|
|
|
|
|
except ImportError:
|
|
|
|
if modulepolicy == 'c':
|
|
|
|
raise
|
|
|
|
|
|
|
|
# Could not load the C extension and pure Python is allowed. So
|
|
|
|
# try to load them.
|
|
|
|
from . import pure
|
|
|
|
modinfo = imp.find_module(stem, pure.__path__)
|
|
|
|
if not modinfo:
|
|
|
|
raise ImportError('could not find mercurial module %s' %
|
|
|
|
name)
|
|
|
|
|
|
|
|
mod = imp.load_module(name, *modinfo)
|
|
|
|
sys.modules[name] = mod
|
|
|
|
return mod
|
|
|
|
|
mercurial: implement a source transforming module loader on Python 3
The most painful part of ensuring Python code runs on both Python 2
and 3 is string encoding. Making this difficult is that string
literals in Python 2 are bytes and string literals in Python 3 are
unicode. So, to ensure consistent types are used, you have to
use "from __future__ import unicode_literals" and/or prefix literals
with their type (e.g. b'foo' or u'foo').
Nearly every string in Mercurial is bytes. So, to use the same source
code on both Python 2 and 3 would require prefixing nearly every
string literal with "b" to make it a byte literal. This is ugly and
not something mpm is willing to do at this point in time.
This patch implements a custom module loader on Python 3 that performs
source transformation to convert string literals (unicode in Python 3)
to byte literals. In effect, it changes Python 3's string literals to
behave like Python 2's.
In addition, the module loader recognizes well-known built-in
functions (getattr, setattr, hasattr) and methods (encode and decode)
that barf when bytes are used and prevents these from being rewritten.
This prevents excessive source changes to accommodate this change
(we would have to rewrite every occurrence of these functions passing
string literals otherwise).
The module loader is only used on Python packages belonging to
Mercurial.
The loader works by tokenizing the loaded source and replacing
"string" tokens if necessary. The modified token stream is
untokenized back to source and loaded like normal. This does add some
overhead. However, this all occurs before caching: .pyc files will
cache the transformed version. This means the transformation penalty
is only paid on first load.
As the extensive inline comments explain, the presence of a custom
source transformer invalidates assumptions made by Python's built-in
bytecode caching mechanism. So, we have to wrap bytecode loading and
writing and add an additional header to bytecode files to facilitate
additional cache validation when the source transformations
change in the future.
There are still a few things this code doesn't handle well, namely
support for zip files as module sources and for extensions. Since
Mercurial doesn't officially support Python 3 yet, I'm inclined to
leave these as to-do items: getting a basic module loading mechanism
in place to unblock further Python 3 porting effort is more important
than comprehensive module importing support.
check-py3-compat.py has been updated to ignore frames. This is
necessary because CPython has built-in code to strip frames from the
built-in importer. When our custom code is present, this doesn't work
and the frames get all messed up. The new code is not perfect. It
works for now. But once you start chasing import failures you find
some edge cases where the files aren't being printed properly. This
only burdens people doing future Python 3 porting work so I'm inclined
to punt on the issue: the most important thing is for the source
transforming module loader to land.
There was a bit of churn in test-check-py3-compat.t because we now
trip up on str/unicode/bytes failures as a result of source
transformation. This is unfortunate but what are you going to do.
It's worth noting that other approaches were investigated.
We considered using a custom file encoding whose decode() would
apply source transformations. This was rejected because it would
require each source file to declare its custom Mercurial encoding.
Furthermore, when changing the source transformation we'd need to
version bump the encoding name otherwise the module caching layer
wouldn't know the .pyc file was invalidated. This would mean mass
updating every file when the source transformation changes. Yuck.
We also considered transforming at the AST layer. However, Python's
ast module is quite gnarly and doing AST transforms is quite
complicated, even for trivial rewrites. There are whole Python packages
that exist to make AST transformations usable. AST transforms would
still require import machinery, so the choice was basically to
perform source-level, token-level, or ast-level transforms.
Token-level rewriting delivers the metadata we need to rewrite
intelligently while being relatively easy to understand. So it won.
General consensus seems to be that this approach is the best available
to avoid bulk rewriting of '' to b''. However, we aren't confident
that this approach will never be a future maintenance burden. This
approach does unblock serious Python 3 porting efforts. So we can
re-evaulate once more work is done to support Python 3.
2016-07-04 21:18:03 +03:00
|
|
|
# Python 3 uses a custom module loader that transforms source code between
|
|
|
|
# source file reading and compilation. This is done by registering a custom
|
|
|
|
# finder that changes the spec for Mercurial modules to use a custom loader.
|
|
|
|
if sys.version_info[0] >= 3:
|
|
|
|
from . import pure
|
|
|
|
import importlib
|
|
|
|
import io
|
|
|
|
import token
|
|
|
|
import tokenize
|
|
|
|
|
|
|
|
class hgpathentryfinder(importlib.abc.MetaPathFinder):
|
|
|
|
"""A sys.meta_path finder that uses a custom module loader."""
|
|
|
|
def find_spec(self, fullname, path, target=None):
|
|
|
|
# Only handle Mercurial-related modules.
|
|
|
|
if not fullname.startswith(('mercurial.', 'hgext.', 'hgext3rd.')):
|
|
|
|
return None
|
|
|
|
|
|
|
|
# This assumes Python 3 doesn't support loading C modules.
|
|
|
|
if fullname in _dualmodules:
|
|
|
|
stem = fullname.split('.')[-1]
|
|
|
|
fullname = 'mercurial.pure.%s' % stem
|
|
|
|
target = pure
|
|
|
|
assert len(path) == 1
|
|
|
|
path = [os.path.join(path[0], 'pure')]
|
|
|
|
|
|
|
|
# Try to find the module using other registered finders.
|
|
|
|
spec = None
|
|
|
|
for finder in sys.meta_path:
|
|
|
|
if finder == self:
|
|
|
|
continue
|
|
|
|
|
|
|
|
spec = finder.find_spec(fullname, path, target=target)
|
|
|
|
if spec:
|
|
|
|
break
|
|
|
|
|
|
|
|
# This is a Mercurial-related module but we couldn't find it
|
|
|
|
# using the previously-registered finders. This likely means
|
|
|
|
# the module doesn't exist.
|
|
|
|
if not spec:
|
|
|
|
return None
|
|
|
|
|
|
|
|
if fullname.startswith('mercurial.pure.'):
|
|
|
|
spec.name = spec.name.replace('.pure.', '.')
|
|
|
|
|
|
|
|
# TODO need to support loaders from alternate specs, like zip
|
|
|
|
# loaders.
|
|
|
|
spec.loader = hgloader(spec.name, spec.origin)
|
|
|
|
return spec
|
|
|
|
|
2016-08-16 06:35:15 +03:00
|
|
|
def replacetokens(tokens, fullname):
|
mercurial: implement a source transforming module loader on Python 3
The most painful part of ensuring Python code runs on both Python 2
and 3 is string encoding. Making this difficult is that string
literals in Python 2 are bytes and string literals in Python 3 are
unicode. So, to ensure consistent types are used, you have to
use "from __future__ import unicode_literals" and/or prefix literals
with their type (e.g. b'foo' or u'foo').
Nearly every string in Mercurial is bytes. So, to use the same source
code on both Python 2 and 3 would require prefixing nearly every
string literal with "b" to make it a byte literal. This is ugly and
not something mpm is willing to do at this point in time.
This patch implements a custom module loader on Python 3 that performs
source transformation to convert string literals (unicode in Python 3)
to byte literals. In effect, it changes Python 3's string literals to
behave like Python 2's.
In addition, the module loader recognizes well-known built-in
functions (getattr, setattr, hasattr) and methods (encode and decode)
that barf when bytes are used and prevents these from being rewritten.
This prevents excessive source changes to accommodate this change
(we would have to rewrite every occurrence of these functions passing
string literals otherwise).
The module loader is only used on Python packages belonging to
Mercurial.
The loader works by tokenizing the loaded source and replacing
"string" tokens if necessary. The modified token stream is
untokenized back to source and loaded like normal. This does add some
overhead. However, this all occurs before caching: .pyc files will
cache the transformed version. This means the transformation penalty
is only paid on first load.
As the extensive inline comments explain, the presence of a custom
source transformer invalidates assumptions made by Python's built-in
bytecode caching mechanism. So, we have to wrap bytecode loading and
writing and add an additional header to bytecode files to facilitate
additional cache validation when the source transformations
change in the future.
There are still a few things this code doesn't handle well, namely
support for zip files as module sources and for extensions. Since
Mercurial doesn't officially support Python 3 yet, I'm inclined to
leave these as to-do items: getting a basic module loading mechanism
in place to unblock further Python 3 porting effort is more important
than comprehensive module importing support.
check-py3-compat.py has been updated to ignore frames. This is
necessary because CPython has built-in code to strip frames from the
built-in importer. When our custom code is present, this doesn't work
and the frames get all messed up. The new code is not perfect. It
works for now. But once you start chasing import failures you find
some edge cases where the files aren't being printed properly. This
only burdens people doing future Python 3 porting work so I'm inclined
to punt on the issue: the most important thing is for the source
transforming module loader to land.
There was a bit of churn in test-check-py3-compat.t because we now
trip up on str/unicode/bytes failures as a result of source
transformation. This is unfortunate but what are you going to do.
It's worth noting that other approaches were investigated.
We considered using a custom file encoding whose decode() would
apply source transformations. This was rejected because it would
require each source file to declare its custom Mercurial encoding.
Furthermore, when changing the source transformation we'd need to
version bump the encoding name otherwise the module caching layer
wouldn't know the .pyc file was invalidated. This would mean mass
updating every file when the source transformation changes. Yuck.
We also considered transforming at the AST layer. However, Python's
ast module is quite gnarly and doing AST transforms is quite
complicated, even for trivial rewrites. There are whole Python packages
that exist to make AST transformations usable. AST transforms would
still require import machinery, so the choice was basically to
perform source-level, token-level, or ast-level transforms.
Token-level rewriting delivers the metadata we need to rewrite
intelligently while being relatively easy to understand. So it won.
General consensus seems to be that this approach is the best available
to avoid bulk rewriting of '' to b''. However, we aren't confident
that this approach will never be a future maintenance burden. This
approach does unblock serious Python 3 porting efforts. So we can
re-evaulate once more work is done to support Python 3.
2016-07-04 21:18:03 +03:00
|
|
|
"""Transform a stream of tokens from raw to Python 3.
|
|
|
|
|
|
|
|
It is called by the custom module loading machinery to rewrite
|
|
|
|
source/tokens between source decoding and compilation.
|
|
|
|
|
|
|
|
Returns a generator of possibly rewritten tokens.
|
|
|
|
|
|
|
|
The input token list may be mutated as part of processing. However,
|
|
|
|
its changes do not necessarily match the output token stream.
|
|
|
|
|
|
|
|
REMEMBER TO CHANGE ``BYTECODEHEADER`` WHEN CHANGING THIS FUNCTION
|
|
|
|
OR CACHED FILES WON'T GET INVALIDATED PROPERLY.
|
|
|
|
"""
|
2016-08-16 06:35:15 +03:00
|
|
|
futureimpline = False
|
2016-10-14 19:55:02 +03:00
|
|
|
|
|
|
|
# The following utility functions access the tokens list and i index of
|
|
|
|
# the for i, t enumerate(tokens) loop below
|
|
|
|
def _isop(j, *o):
|
|
|
|
"""Assert that tokens[j] is an OP with one of the given values"""
|
|
|
|
try:
|
|
|
|
return tokens[j].type == token.OP and tokens[j].string in o
|
|
|
|
except IndexError:
|
|
|
|
return False
|
|
|
|
|
|
|
|
def _findargnofcall(n):
|
|
|
|
"""Find arg n of a call expression (start at 0)
|
|
|
|
|
|
|
|
Returns index of the first token of that argument, or None if
|
|
|
|
there is not that many arguments.
|
|
|
|
|
|
|
|
Assumes that token[i + 1] is '('.
|
|
|
|
|
|
|
|
"""
|
|
|
|
nested = 0
|
|
|
|
for j in range(i + 2, len(tokens)):
|
|
|
|
if _isop(j, ')', ']', '}'):
|
|
|
|
# end of call, tuple, subscription or dict / set
|
|
|
|
nested -= 1
|
|
|
|
if nested < 0:
|
|
|
|
return None
|
|
|
|
elif n == 0:
|
|
|
|
# this is the starting position of arg
|
|
|
|
return j
|
|
|
|
elif _isop(j, '(', '[', '{'):
|
|
|
|
nested += 1
|
|
|
|
elif _isop(j, ',') and nested == 0:
|
|
|
|
n -= 1
|
|
|
|
|
|
|
|
return None
|
|
|
|
|
|
|
|
def _ensureunicode(j):
|
|
|
|
"""Make sure the token at j is a unicode string
|
|
|
|
|
|
|
|
This rewrites a string token to include the unicode literal prefix
|
|
|
|
so the string transformer won't add the byte prefix.
|
|
|
|
|
|
|
|
Ignores tokens that are not strings. Assumes bounds checking has
|
|
|
|
already been done.
|
|
|
|
|
|
|
|
"""
|
|
|
|
st = tokens[j]
|
|
|
|
if st.type == token.STRING and st.string.startswith(("'", '"')):
|
|
|
|
rt = tokenize.TokenInfo(st.type, 'u%s' % st.string,
|
|
|
|
st.start, st.end, st.line)
|
|
|
|
tokens[j] = rt
|
|
|
|
|
mercurial: implement a source transforming module loader on Python 3
The most painful part of ensuring Python code runs on both Python 2
and 3 is string encoding. Making this difficult is that string
literals in Python 2 are bytes and string literals in Python 3 are
unicode. So, to ensure consistent types are used, you have to
use "from __future__ import unicode_literals" and/or prefix literals
with their type (e.g. b'foo' or u'foo').
Nearly every string in Mercurial is bytes. So, to use the same source
code on both Python 2 and 3 would require prefixing nearly every
string literal with "b" to make it a byte literal. This is ugly and
not something mpm is willing to do at this point in time.
This patch implements a custom module loader on Python 3 that performs
source transformation to convert string literals (unicode in Python 3)
to byte literals. In effect, it changes Python 3's string literals to
behave like Python 2's.
In addition, the module loader recognizes well-known built-in
functions (getattr, setattr, hasattr) and methods (encode and decode)
that barf when bytes are used and prevents these from being rewritten.
This prevents excessive source changes to accommodate this change
(we would have to rewrite every occurrence of these functions passing
string literals otherwise).
The module loader is only used on Python packages belonging to
Mercurial.
The loader works by tokenizing the loaded source and replacing
"string" tokens if necessary. The modified token stream is
untokenized back to source and loaded like normal. This does add some
overhead. However, this all occurs before caching: .pyc files will
cache the transformed version. This means the transformation penalty
is only paid on first load.
As the extensive inline comments explain, the presence of a custom
source transformer invalidates assumptions made by Python's built-in
bytecode caching mechanism. So, we have to wrap bytecode loading and
writing and add an additional header to bytecode files to facilitate
additional cache validation when the source transformations
change in the future.
There are still a few things this code doesn't handle well, namely
support for zip files as module sources and for extensions. Since
Mercurial doesn't officially support Python 3 yet, I'm inclined to
leave these as to-do items: getting a basic module loading mechanism
in place to unblock further Python 3 porting effort is more important
than comprehensive module importing support.
check-py3-compat.py has been updated to ignore frames. This is
necessary because CPython has built-in code to strip frames from the
built-in importer. When our custom code is present, this doesn't work
and the frames get all messed up. The new code is not perfect. It
works for now. But once you start chasing import failures you find
some edge cases where the files aren't being printed properly. This
only burdens people doing future Python 3 porting work so I'm inclined
to punt on the issue: the most important thing is for the source
transforming module loader to land.
There was a bit of churn in test-check-py3-compat.t because we now
trip up on str/unicode/bytes failures as a result of source
transformation. This is unfortunate but what are you going to do.
It's worth noting that other approaches were investigated.
We considered using a custom file encoding whose decode() would
apply source transformations. This was rejected because it would
require each source file to declare its custom Mercurial encoding.
Furthermore, when changing the source transformation we'd need to
version bump the encoding name otherwise the module caching layer
wouldn't know the .pyc file was invalidated. This would mean mass
updating every file when the source transformation changes. Yuck.
We also considered transforming at the AST layer. However, Python's
ast module is quite gnarly and doing AST transforms is quite
complicated, even for trivial rewrites. There are whole Python packages
that exist to make AST transformations usable. AST transforms would
still require import machinery, so the choice was basically to
perform source-level, token-level, or ast-level transforms.
Token-level rewriting delivers the metadata we need to rewrite
intelligently while being relatively easy to understand. So it won.
General consensus seems to be that this approach is the best available
to avoid bulk rewriting of '' to b''. However, we aren't confident
that this approach will never be a future maintenance burden. This
approach does unblock serious Python 3 porting efforts. So we can
re-evaulate once more work is done to support Python 3.
2016-07-04 21:18:03 +03:00
|
|
|
for i, t in enumerate(tokens):
|
|
|
|
# Convert most string literals to byte literals. String literals
|
|
|
|
# in Python 2 are bytes. String literals in Python 3 are unicode.
|
|
|
|
# Most strings in Mercurial are bytes and unicode strings are rare.
|
|
|
|
# Rather than rewrite all string literals to use ``b''`` to indicate
|
|
|
|
# byte strings, we apply this token transformer to insert the ``b``
|
|
|
|
# prefix nearly everywhere.
|
|
|
|
if t.type == token.STRING:
|
|
|
|
s = t.string
|
|
|
|
|
|
|
|
# Preserve docstrings as string literals. This is inconsistent
|
|
|
|
# with regular unprefixed strings. However, the
|
|
|
|
# "from __future__" parsing (which allows a module docstring to
|
|
|
|
# exist before it) doesn't properly handle the docstring if it
|
|
|
|
# is b''' prefixed, leading to a SyntaxError. We leave all
|
|
|
|
# docstrings as unprefixed to avoid this. This means Mercurial
|
|
|
|
# components touching docstrings need to handle unicode,
|
|
|
|
# unfortunately.
|
|
|
|
if s[0:3] in ("'''", '"""'):
|
|
|
|
yield t
|
|
|
|
continue
|
|
|
|
|
|
|
|
# If the first character isn't a quote, it is likely a string
|
|
|
|
# prefixing character (such as 'b', 'u', or 'r'. Ignore.
|
|
|
|
if s[0] not in ("'", '"'):
|
|
|
|
yield t
|
|
|
|
continue
|
|
|
|
|
|
|
|
# String literal. Prefix to make a b'' string.
|
|
|
|
yield tokenize.TokenInfo(t.type, 'b%s' % s, t.start, t.end,
|
|
|
|
t.line)
|
|
|
|
continue
|
|
|
|
|
2016-08-16 06:35:15 +03:00
|
|
|
# Insert compatibility imports at "from __future__ import" line.
|
|
|
|
# No '\n' should be added to preserve line numbers.
|
|
|
|
if (t.type == token.NAME and t.string == 'import' and
|
|
|
|
all(u.type == token.NAME for u in tokens[i - 2:i]) and
|
|
|
|
[u.string for u in tokens[i - 2:i]] == ['from', '__future__']):
|
|
|
|
futureimpline = True
|
|
|
|
if t.type == token.NEWLINE and futureimpline:
|
|
|
|
futureimpline = False
|
|
|
|
if fullname == 'mercurial.pycompat':
|
|
|
|
yield t
|
|
|
|
continue
|
|
|
|
r, c = t.start
|
|
|
|
l = (b'; from mercurial.pycompat import '
|
|
|
|
b'delattr, getattr, hasattr, setattr, xrange\n')
|
|
|
|
for u in tokenize.tokenize(io.BytesIO(l).readline):
|
|
|
|
if u.type in (tokenize.ENCODING, token.ENDMARKER):
|
|
|
|
continue
|
|
|
|
yield tokenize.TokenInfo(u.type, u.string,
|
|
|
|
(r, c + u.start[1]),
|
|
|
|
(r, c + u.end[1]),
|
|
|
|
'')
|
|
|
|
continue
|
|
|
|
|
mercurial: implement a source transforming module loader on Python 3
The most painful part of ensuring Python code runs on both Python 2
and 3 is string encoding. Making this difficult is that string
literals in Python 2 are bytes and string literals in Python 3 are
unicode. So, to ensure consistent types are used, you have to
use "from __future__ import unicode_literals" and/or prefix literals
with their type (e.g. b'foo' or u'foo').
Nearly every string in Mercurial is bytes. So, to use the same source
code on both Python 2 and 3 would require prefixing nearly every
string literal with "b" to make it a byte literal. This is ugly and
not something mpm is willing to do at this point in time.
This patch implements a custom module loader on Python 3 that performs
source transformation to convert string literals (unicode in Python 3)
to byte literals. In effect, it changes Python 3's string literals to
behave like Python 2's.
In addition, the module loader recognizes well-known built-in
functions (getattr, setattr, hasattr) and methods (encode and decode)
that barf when bytes are used and prevents these from being rewritten.
This prevents excessive source changes to accommodate this change
(we would have to rewrite every occurrence of these functions passing
string literals otherwise).
The module loader is only used on Python packages belonging to
Mercurial.
The loader works by tokenizing the loaded source and replacing
"string" tokens if necessary. The modified token stream is
untokenized back to source and loaded like normal. This does add some
overhead. However, this all occurs before caching: .pyc files will
cache the transformed version. This means the transformation penalty
is only paid on first load.
As the extensive inline comments explain, the presence of a custom
source transformer invalidates assumptions made by Python's built-in
bytecode caching mechanism. So, we have to wrap bytecode loading and
writing and add an additional header to bytecode files to facilitate
additional cache validation when the source transformations
change in the future.
There are still a few things this code doesn't handle well, namely
support for zip files as module sources and for extensions. Since
Mercurial doesn't officially support Python 3 yet, I'm inclined to
leave these as to-do items: getting a basic module loading mechanism
in place to unblock further Python 3 porting effort is more important
than comprehensive module importing support.
check-py3-compat.py has been updated to ignore frames. This is
necessary because CPython has built-in code to strip frames from the
built-in importer. When our custom code is present, this doesn't work
and the frames get all messed up. The new code is not perfect. It
works for now. But once you start chasing import failures you find
some edge cases where the files aren't being printed properly. This
only burdens people doing future Python 3 porting work so I'm inclined
to punt on the issue: the most important thing is for the source
transforming module loader to land.
There was a bit of churn in test-check-py3-compat.t because we now
trip up on str/unicode/bytes failures as a result of source
transformation. This is unfortunate but what are you going to do.
It's worth noting that other approaches were investigated.
We considered using a custom file encoding whose decode() would
apply source transformations. This was rejected because it would
require each source file to declare its custom Mercurial encoding.
Furthermore, when changing the source transformation we'd need to
version bump the encoding name otherwise the module caching layer
wouldn't know the .pyc file was invalidated. This would mean mass
updating every file when the source transformation changes. Yuck.
We also considered transforming at the AST layer. However, Python's
ast module is quite gnarly and doing AST transforms is quite
complicated, even for trivial rewrites. There are whole Python packages
that exist to make AST transformations usable. AST transforms would
still require import machinery, so the choice was basically to
perform source-level, token-level, or ast-level transforms.
Token-level rewriting delivers the metadata we need to rewrite
intelligently while being relatively easy to understand. So it won.
General consensus seems to be that this approach is the best available
to avoid bulk rewriting of '' to b''. However, we aren't confident
that this approach will never be a future maintenance burden. This
approach does unblock serious Python 3 porting efforts. So we can
re-evaulate once more work is done to support Python 3.
2016-07-04 21:18:03 +03:00
|
|
|
# This looks like a function call.
|
2016-10-14 19:55:02 +03:00
|
|
|
if t.type == token.NAME and _isop(i + 1, '('):
|
mercurial: implement a source transforming module loader on Python 3
The most painful part of ensuring Python code runs on both Python 2
and 3 is string encoding. Making this difficult is that string
literals in Python 2 are bytes and string literals in Python 3 are
unicode. So, to ensure consistent types are used, you have to
use "from __future__ import unicode_literals" and/or prefix literals
with their type (e.g. b'foo' or u'foo').
Nearly every string in Mercurial is bytes. So, to use the same source
code on both Python 2 and 3 would require prefixing nearly every
string literal with "b" to make it a byte literal. This is ugly and
not something mpm is willing to do at this point in time.
This patch implements a custom module loader on Python 3 that performs
source transformation to convert string literals (unicode in Python 3)
to byte literals. In effect, it changes Python 3's string literals to
behave like Python 2's.
In addition, the module loader recognizes well-known built-in
functions (getattr, setattr, hasattr) and methods (encode and decode)
that barf when bytes are used and prevents these from being rewritten.
This prevents excessive source changes to accommodate this change
(we would have to rewrite every occurrence of these functions passing
string literals otherwise).
The module loader is only used on Python packages belonging to
Mercurial.
The loader works by tokenizing the loaded source and replacing
"string" tokens if necessary. The modified token stream is
untokenized back to source and loaded like normal. This does add some
overhead. However, this all occurs before caching: .pyc files will
cache the transformed version. This means the transformation penalty
is only paid on first load.
As the extensive inline comments explain, the presence of a custom
source transformer invalidates assumptions made by Python's built-in
bytecode caching mechanism. So, we have to wrap bytecode loading and
writing and add an additional header to bytecode files to facilitate
additional cache validation when the source transformations
change in the future.
There are still a few things this code doesn't handle well, namely
support for zip files as module sources and for extensions. Since
Mercurial doesn't officially support Python 3 yet, I'm inclined to
leave these as to-do items: getting a basic module loading mechanism
in place to unblock further Python 3 porting effort is more important
than comprehensive module importing support.
check-py3-compat.py has been updated to ignore frames. This is
necessary because CPython has built-in code to strip frames from the
built-in importer. When our custom code is present, this doesn't work
and the frames get all messed up. The new code is not perfect. It
works for now. But once you start chasing import failures you find
some edge cases where the files aren't being printed properly. This
only burdens people doing future Python 3 porting work so I'm inclined
to punt on the issue: the most important thing is for the source
transforming module loader to land.
There was a bit of churn in test-check-py3-compat.t because we now
trip up on str/unicode/bytes failures as a result of source
transformation. This is unfortunate but what are you going to do.
It's worth noting that other approaches were investigated.
We considered using a custom file encoding whose decode() would
apply source transformations. This was rejected because it would
require each source file to declare its custom Mercurial encoding.
Furthermore, when changing the source transformation we'd need to
version bump the encoding name otherwise the module caching layer
wouldn't know the .pyc file was invalidated. This would mean mass
updating every file when the source transformation changes. Yuck.
We also considered transforming at the AST layer. However, Python's
ast module is quite gnarly and doing AST transforms is quite
complicated, even for trivial rewrites. There are whole Python packages
that exist to make AST transformations usable. AST transforms would
still require import machinery, so the choice was basically to
perform source-level, token-level, or ast-level transforms.
Token-level rewriting delivers the metadata we need to rewrite
intelligently while being relatively easy to understand. So it won.
General consensus seems to be that this approach is the best available
to avoid bulk rewriting of '' to b''. However, we aren't confident
that this approach will never be a future maintenance burden. This
approach does unblock serious Python 3 porting efforts. So we can
re-evaulate once more work is done to support Python 3.
2016-07-04 21:18:03 +03:00
|
|
|
fn = t.string
|
|
|
|
|
|
|
|
# *attr() builtins don't accept byte strings to 2nd argument.
|
2016-10-14 19:55:02 +03:00
|
|
|
if (fn in ('getattr', 'setattr', 'hasattr', 'safehasattr') and
|
|
|
|
not _isop(i - 1, '.')):
|
|
|
|
arg1idx = _findargnofcall(1)
|
|
|
|
if arg1idx is not None:
|
|
|
|
_ensureunicode(arg1idx)
|
mercurial: implement a source transforming module loader on Python 3
The most painful part of ensuring Python code runs on both Python 2
and 3 is string encoding. Making this difficult is that string
literals in Python 2 are bytes and string literals in Python 3 are
unicode. So, to ensure consistent types are used, you have to
use "from __future__ import unicode_literals" and/or prefix literals
with their type (e.g. b'foo' or u'foo').
Nearly every string in Mercurial is bytes. So, to use the same source
code on both Python 2 and 3 would require prefixing nearly every
string literal with "b" to make it a byte literal. This is ugly and
not something mpm is willing to do at this point in time.
This patch implements a custom module loader on Python 3 that performs
source transformation to convert string literals (unicode in Python 3)
to byte literals. In effect, it changes Python 3's string literals to
behave like Python 2's.
In addition, the module loader recognizes well-known built-in
functions (getattr, setattr, hasattr) and methods (encode and decode)
that barf when bytes are used and prevents these from being rewritten.
This prevents excessive source changes to accommodate this change
(we would have to rewrite every occurrence of these functions passing
string literals otherwise).
The module loader is only used on Python packages belonging to
Mercurial.
The loader works by tokenizing the loaded source and replacing
"string" tokens if necessary. The modified token stream is
untokenized back to source and loaded like normal. This does add some
overhead. However, this all occurs before caching: .pyc files will
cache the transformed version. This means the transformation penalty
is only paid on first load.
As the extensive inline comments explain, the presence of a custom
source transformer invalidates assumptions made by Python's built-in
bytecode caching mechanism. So, we have to wrap bytecode loading and
writing and add an additional header to bytecode files to facilitate
additional cache validation when the source transformations
change in the future.
There are still a few things this code doesn't handle well, namely
support for zip files as module sources and for extensions. Since
Mercurial doesn't officially support Python 3 yet, I'm inclined to
leave these as to-do items: getting a basic module loading mechanism
in place to unblock further Python 3 porting effort is more important
than comprehensive module importing support.
check-py3-compat.py has been updated to ignore frames. This is
necessary because CPython has built-in code to strip frames from the
built-in importer. When our custom code is present, this doesn't work
and the frames get all messed up. The new code is not perfect. It
works for now. But once you start chasing import failures you find
some edge cases where the files aren't being printed properly. This
only burdens people doing future Python 3 porting work so I'm inclined
to punt on the issue: the most important thing is for the source
transforming module loader to land.
There was a bit of churn in test-check-py3-compat.t because we now
trip up on str/unicode/bytes failures as a result of source
transformation. This is unfortunate but what are you going to do.
It's worth noting that other approaches were investigated.
We considered using a custom file encoding whose decode() would
apply source transformations. This was rejected because it would
require each source file to declare its custom Mercurial encoding.
Furthermore, when changing the source transformation we'd need to
version bump the encoding name otherwise the module caching layer
wouldn't know the .pyc file was invalidated. This would mean mass
updating every file when the source transformation changes. Yuck.
We also considered transforming at the AST layer. However, Python's
ast module is quite gnarly and doing AST transforms is quite
complicated, even for trivial rewrites. There are whole Python packages
that exist to make AST transformations usable. AST transforms would
still require import machinery, so the choice was basically to
perform source-level, token-level, or ast-level transforms.
Token-level rewriting delivers the metadata we need to rewrite
intelligently while being relatively easy to understand. So it won.
General consensus seems to be that this approach is the best available
to avoid bulk rewriting of '' to b''. However, we aren't confident
that this approach will never be a future maintenance burden. This
approach does unblock serious Python 3 porting efforts. So we can
re-evaulate once more work is done to support Python 3.
2016-07-04 21:18:03 +03:00
|
|
|
|
|
|
|
# .encode() and .decode() on str/bytes/unicode don't accept
|
2016-10-14 19:55:02 +03:00
|
|
|
# byte strings on Python 3.
|
|
|
|
elif fn in ('encode', 'decode') and _isop(i - 1, '.'):
|
|
|
|
for argn in range(2):
|
|
|
|
argidx = _findargnofcall(argn)
|
|
|
|
if argidx is not None:
|
|
|
|
_ensureunicode(argidx)
|
|
|
|
|
|
|
|
# Bare open call (not an attribute on something else), the
|
|
|
|
# second argument (mode) must be a string, not bytes
|
|
|
|
elif fn == 'open' and not _isop(i - 1, '.'):
|
|
|
|
arg1idx = _findargnofcall(1)
|
|
|
|
if arg1idx is not None:
|
|
|
|
_ensureunicode(arg1idx)
|
py3: a second argument to open can't be bytes
This fixes open(filename, 'r'), open(filename, 'w'), etc. calls. In Python
3, that second argument *must* be a string, you can't use bytes.
The fix is the same as used with getattr() (where the second argument must
also always be a string); in the tokenizer, where we detect calls, if there
is something that looks like a call to open (and is not an attribute, so
the previous token is not a "." dot) then make sure that that second
argument is not converted to a `bytes` object instead.
There is some remaining issue where the current transformer will also rewrite
open(f('foo')).
However this also affect function for which we perform similar rewrite
('getattr', 'setattr', 'hasattr', 'safehasattr') and will be dealt with in a
follow up.
2016-10-09 15:10:01 +03:00
|
|
|
|
2016-10-07 16:29:57 +03:00
|
|
|
# It changes iteritems to items as iteritems is not
|
|
|
|
# present in Python 3 world.
|
2016-10-14 19:55:02 +03:00
|
|
|
elif fn == 'iteritems':
|
2016-10-07 16:29:57 +03:00
|
|
|
yield tokenize.TokenInfo(t.type, 'items',
|
|
|
|
t.start, t.end, t.line)
|
|
|
|
continue
|
|
|
|
|
mercurial: implement a source transforming module loader on Python 3
The most painful part of ensuring Python code runs on both Python 2
and 3 is string encoding. Making this difficult is that string
literals in Python 2 are bytes and string literals in Python 3 are
unicode. So, to ensure consistent types are used, you have to
use "from __future__ import unicode_literals" and/or prefix literals
with their type (e.g. b'foo' or u'foo').
Nearly every string in Mercurial is bytes. So, to use the same source
code on both Python 2 and 3 would require prefixing nearly every
string literal with "b" to make it a byte literal. This is ugly and
not something mpm is willing to do at this point in time.
This patch implements a custom module loader on Python 3 that performs
source transformation to convert string literals (unicode in Python 3)
to byte literals. In effect, it changes Python 3's string literals to
behave like Python 2's.
In addition, the module loader recognizes well-known built-in
functions (getattr, setattr, hasattr) and methods (encode and decode)
that barf when bytes are used and prevents these from being rewritten.
This prevents excessive source changes to accommodate this change
(we would have to rewrite every occurrence of these functions passing
string literals otherwise).
The module loader is only used on Python packages belonging to
Mercurial.
The loader works by tokenizing the loaded source and replacing
"string" tokens if necessary. The modified token stream is
untokenized back to source and loaded like normal. This does add some
overhead. However, this all occurs before caching: .pyc files will
cache the transformed version. This means the transformation penalty
is only paid on first load.
As the extensive inline comments explain, the presence of a custom
source transformer invalidates assumptions made by Python's built-in
bytecode caching mechanism. So, we have to wrap bytecode loading and
writing and add an additional header to bytecode files to facilitate
additional cache validation when the source transformations
change in the future.
There are still a few things this code doesn't handle well, namely
support for zip files as module sources and for extensions. Since
Mercurial doesn't officially support Python 3 yet, I'm inclined to
leave these as to-do items: getting a basic module loading mechanism
in place to unblock further Python 3 porting effort is more important
than comprehensive module importing support.
check-py3-compat.py has been updated to ignore frames. This is
necessary because CPython has built-in code to strip frames from the
built-in importer. When our custom code is present, this doesn't work
and the frames get all messed up. The new code is not perfect. It
works for now. But once you start chasing import failures you find
some edge cases where the files aren't being printed properly. This
only burdens people doing future Python 3 porting work so I'm inclined
to punt on the issue: the most important thing is for the source
transforming module loader to land.
There was a bit of churn in test-check-py3-compat.t because we now
trip up on str/unicode/bytes failures as a result of source
transformation. This is unfortunate but what are you going to do.
It's worth noting that other approaches were investigated.
We considered using a custom file encoding whose decode() would
apply source transformations. This was rejected because it would
require each source file to declare its custom Mercurial encoding.
Furthermore, when changing the source transformation we'd need to
version bump the encoding name otherwise the module caching layer
wouldn't know the .pyc file was invalidated. This would mean mass
updating every file when the source transformation changes. Yuck.
We also considered transforming at the AST layer. However, Python's
ast module is quite gnarly and doing AST transforms is quite
complicated, even for trivial rewrites. There are whole Python packages
that exist to make AST transformations usable. AST transforms would
still require import machinery, so the choice was basically to
perform source-level, token-level, or ast-level transforms.
Token-level rewriting delivers the metadata we need to rewrite
intelligently while being relatively easy to understand. So it won.
General consensus seems to be that this approach is the best available
to avoid bulk rewriting of '' to b''. However, we aren't confident
that this approach will never be a future maintenance burden. This
approach does unblock serious Python 3 porting efforts. So we can
re-evaulate once more work is done to support Python 3.
2016-07-04 21:18:03 +03:00
|
|
|
# Emit unmodified token.
|
|
|
|
yield t
|
|
|
|
|
|
|
|
# Header to add to bytecode files. This MUST be changed when
|
|
|
|
# ``replacetoken`` or any mechanism that changes semantics of module
|
|
|
|
# loading is changed. Otherwise cached bytecode may get loaded without
|
|
|
|
# the new transformation mechanisms applied.
|
2016-10-14 19:55:02 +03:00
|
|
|
BYTECODEHEADER = b'HG\x00\x06'
|
mercurial: implement a source transforming module loader on Python 3
The most painful part of ensuring Python code runs on both Python 2
and 3 is string encoding. Making this difficult is that string
literals in Python 2 are bytes and string literals in Python 3 are
unicode. So, to ensure consistent types are used, you have to
use "from __future__ import unicode_literals" and/or prefix literals
with their type (e.g. b'foo' or u'foo').
Nearly every string in Mercurial is bytes. So, to use the same source
code on both Python 2 and 3 would require prefixing nearly every
string literal with "b" to make it a byte literal. This is ugly and
not something mpm is willing to do at this point in time.
This patch implements a custom module loader on Python 3 that performs
source transformation to convert string literals (unicode in Python 3)
to byte literals. In effect, it changes Python 3's string literals to
behave like Python 2's.
In addition, the module loader recognizes well-known built-in
functions (getattr, setattr, hasattr) and methods (encode and decode)
that barf when bytes are used and prevents these from being rewritten.
This prevents excessive source changes to accommodate this change
(we would have to rewrite every occurrence of these functions passing
string literals otherwise).
The module loader is only used on Python packages belonging to
Mercurial.
The loader works by tokenizing the loaded source and replacing
"string" tokens if necessary. The modified token stream is
untokenized back to source and loaded like normal. This does add some
overhead. However, this all occurs before caching: .pyc files will
cache the transformed version. This means the transformation penalty
is only paid on first load.
As the extensive inline comments explain, the presence of a custom
source transformer invalidates assumptions made by Python's built-in
bytecode caching mechanism. So, we have to wrap bytecode loading and
writing and add an additional header to bytecode files to facilitate
additional cache validation when the source transformations
change in the future.
There are still a few things this code doesn't handle well, namely
support for zip files as module sources and for extensions. Since
Mercurial doesn't officially support Python 3 yet, I'm inclined to
leave these as to-do items: getting a basic module loading mechanism
in place to unblock further Python 3 porting effort is more important
than comprehensive module importing support.
check-py3-compat.py has been updated to ignore frames. This is
necessary because CPython has built-in code to strip frames from the
built-in importer. When our custom code is present, this doesn't work
and the frames get all messed up. The new code is not perfect. It
works for now. But once you start chasing import failures you find
some edge cases where the files aren't being printed properly. This
only burdens people doing future Python 3 porting work so I'm inclined
to punt on the issue: the most important thing is for the source
transforming module loader to land.
There was a bit of churn in test-check-py3-compat.t because we now
trip up on str/unicode/bytes failures as a result of source
transformation. This is unfortunate but what are you going to do.
It's worth noting that other approaches were investigated.
We considered using a custom file encoding whose decode() would
apply source transformations. This was rejected because it would
require each source file to declare its custom Mercurial encoding.
Furthermore, when changing the source transformation we'd need to
version bump the encoding name otherwise the module caching layer
wouldn't know the .pyc file was invalidated. This would mean mass
updating every file when the source transformation changes. Yuck.
We also considered transforming at the AST layer. However, Python's
ast module is quite gnarly and doing AST transforms is quite
complicated, even for trivial rewrites. There are whole Python packages
that exist to make AST transformations usable. AST transforms would
still require import machinery, so the choice was basically to
perform source-level, token-level, or ast-level transforms.
Token-level rewriting delivers the metadata we need to rewrite
intelligently while being relatively easy to understand. So it won.
General consensus seems to be that this approach is the best available
to avoid bulk rewriting of '' to b''. However, we aren't confident
that this approach will never be a future maintenance burden. This
approach does unblock serious Python 3 porting efforts. So we can
re-evaulate once more work is done to support Python 3.
2016-07-04 21:18:03 +03:00
|
|
|
|
|
|
|
class hgloader(importlib.machinery.SourceFileLoader):
|
|
|
|
"""Custom module loader that transforms source code.
|
|
|
|
|
|
|
|
When the source code is converted to a code object, we transform
|
|
|
|
certain patterns to be Python 3 compatible. This allows us to write code
|
|
|
|
that is natively Python 2 and compatible with Python 3 without
|
|
|
|
making the code excessively ugly.
|
|
|
|
|
|
|
|
We do this by transforming the token stream between parse and compile.
|
|
|
|
|
|
|
|
Implementing transformations invalidates caching assumptions made
|
|
|
|
by the built-in importer. The built-in importer stores a header on
|
|
|
|
saved bytecode files indicating the Python/bytecode version. If the
|
|
|
|
version changes, the cached bytecode is ignored. The Mercurial
|
|
|
|
transformations could change at any time. This means we need to check
|
|
|
|
that cached bytecode was generated with the current transformation
|
|
|
|
code or there could be a mismatch between cached bytecode and what
|
|
|
|
would be generated from this class.
|
|
|
|
|
|
|
|
We supplement the bytecode caching layer by wrapping ``get_data``
|
|
|
|
and ``set_data``. These functions are called when the
|
|
|
|
``SourceFileLoader`` retrieves and saves bytecode cache files,
|
|
|
|
respectively. We simply add an additional header on the file. As
|
|
|
|
long as the version in this file is changed when semantics change,
|
|
|
|
cached bytecode should be invalidated when transformations change.
|
|
|
|
|
|
|
|
The added header has the form ``HG<VERSION>``. That is a literal
|
|
|
|
``HG`` with 2 binary bytes indicating the transformation version.
|
|
|
|
"""
|
|
|
|
def get_data(self, path):
|
|
|
|
data = super(hgloader, self).get_data(path)
|
|
|
|
|
|
|
|
if not path.endswith(tuple(importlib.machinery.BYTECODE_SUFFIXES)):
|
|
|
|
return data
|
|
|
|
|
|
|
|
# There should be a header indicating the Mercurial transformation
|
|
|
|
# version. If it doesn't exist or doesn't match the current version,
|
|
|
|
# we raise an OSError because that is what
|
|
|
|
# ``SourceFileLoader.get_code()`` expects when loading bytecode
|
|
|
|
# paths to indicate the cached file is "bad."
|
|
|
|
if data[0:2] != b'HG':
|
|
|
|
raise OSError('no hg header')
|
|
|
|
if data[0:4] != BYTECODEHEADER:
|
|
|
|
raise OSError('hg header version mismatch')
|
|
|
|
|
|
|
|
return data[4:]
|
|
|
|
|
|
|
|
def set_data(self, path, data, *args, **kwargs):
|
|
|
|
if path.endswith(tuple(importlib.machinery.BYTECODE_SUFFIXES)):
|
|
|
|
data = BYTECODEHEADER + data
|
|
|
|
|
|
|
|
return super(hgloader, self).set_data(path, data, *args, **kwargs)
|
|
|
|
|
|
|
|
def source_to_code(self, data, path):
|
|
|
|
"""Perform token transformation before compilation."""
|
|
|
|
buf = io.BytesIO(data)
|
|
|
|
tokens = tokenize.tokenize(buf.readline)
|
2016-08-16 06:35:15 +03:00
|
|
|
data = tokenize.untokenize(replacetokens(list(tokens), self.name))
|
mercurial: implement a source transforming module loader on Python 3
The most painful part of ensuring Python code runs on both Python 2
and 3 is string encoding. Making this difficult is that string
literals in Python 2 are bytes and string literals in Python 3 are
unicode. So, to ensure consistent types are used, you have to
use "from __future__ import unicode_literals" and/or prefix literals
with their type (e.g. b'foo' or u'foo').
Nearly every string in Mercurial is bytes. So, to use the same source
code on both Python 2 and 3 would require prefixing nearly every
string literal with "b" to make it a byte literal. This is ugly and
not something mpm is willing to do at this point in time.
This patch implements a custom module loader on Python 3 that performs
source transformation to convert string literals (unicode in Python 3)
to byte literals. In effect, it changes Python 3's string literals to
behave like Python 2's.
In addition, the module loader recognizes well-known built-in
functions (getattr, setattr, hasattr) and methods (encode and decode)
that barf when bytes are used and prevents these from being rewritten.
This prevents excessive source changes to accommodate this change
(we would have to rewrite every occurrence of these functions passing
string literals otherwise).
The module loader is only used on Python packages belonging to
Mercurial.
The loader works by tokenizing the loaded source and replacing
"string" tokens if necessary. The modified token stream is
untokenized back to source and loaded like normal. This does add some
overhead. However, this all occurs before caching: .pyc files will
cache the transformed version. This means the transformation penalty
is only paid on first load.
As the extensive inline comments explain, the presence of a custom
source transformer invalidates assumptions made by Python's built-in
bytecode caching mechanism. So, we have to wrap bytecode loading and
writing and add an additional header to bytecode files to facilitate
additional cache validation when the source transformations
change in the future.
There are still a few things this code doesn't handle well, namely
support for zip files as module sources and for extensions. Since
Mercurial doesn't officially support Python 3 yet, I'm inclined to
leave these as to-do items: getting a basic module loading mechanism
in place to unblock further Python 3 porting effort is more important
than comprehensive module importing support.
check-py3-compat.py has been updated to ignore frames. This is
necessary because CPython has built-in code to strip frames from the
built-in importer. When our custom code is present, this doesn't work
and the frames get all messed up. The new code is not perfect. It
works for now. But once you start chasing import failures you find
some edge cases where the files aren't being printed properly. This
only burdens people doing future Python 3 porting work so I'm inclined
to punt on the issue: the most important thing is for the source
transforming module loader to land.
There was a bit of churn in test-check-py3-compat.t because we now
trip up on str/unicode/bytes failures as a result of source
transformation. This is unfortunate but what are you going to do.
It's worth noting that other approaches were investigated.
We considered using a custom file encoding whose decode() would
apply source transformations. This was rejected because it would
require each source file to declare its custom Mercurial encoding.
Furthermore, when changing the source transformation we'd need to
version bump the encoding name otherwise the module caching layer
wouldn't know the .pyc file was invalidated. This would mean mass
updating every file when the source transformation changes. Yuck.
We also considered transforming at the AST layer. However, Python's
ast module is quite gnarly and doing AST transforms is quite
complicated, even for trivial rewrites. There are whole Python packages
that exist to make AST transformations usable. AST transforms would
still require import machinery, so the choice was basically to
perform source-level, token-level, or ast-level transforms.
Token-level rewriting delivers the metadata we need to rewrite
intelligently while being relatively easy to understand. So it won.
General consensus seems to be that this approach is the best available
to avoid bulk rewriting of '' to b''. However, we aren't confident
that this approach will never be a future maintenance burden. This
approach does unblock serious Python 3 porting efforts. So we can
re-evaulate once more work is done to support Python 3.
2016-07-04 21:18:03 +03:00
|
|
|
# Python's built-in importer strips frames from exceptions raised
|
|
|
|
# for this code. Unfortunately, that mechanism isn't extensible
|
|
|
|
# and our frame will be blamed for the import failure. There
|
|
|
|
# are extremely hacky ways to do frame stripping. We haven't
|
|
|
|
# implemented them because they are very ugly.
|
|
|
|
return super(hgloader, self).source_to_code(data, path)
|
|
|
|
|
mercurial: implement import hook for handling C/Python modules
There are a handful of modules that have both pure Python and C
extension implementations. Currently, setup.py copies files from
mercurial/pure/*.py to mercurial/ during the install process if C
extensions are not available. This way, "import mercurial.X" will
work whether C extensions are available or not.
This approach has a few drawbacks. First, there aren't run-time checks
verifying the C extensions are loaded when they should be. This could
lead to accidental use of the slower pure Python modules. Second, the
C extensions aren't compatible with PyPy and running Mercurial with
PyPy requires installing Mercurial - you can't run ./hg from a source
checkout. This makes developing while running PyPy somewhat difficult.
This patch implements a PEP-302 import hook for finding and loading the
modules with both C and Python implementations. When a module with dual
implementations is requested for import, its import is handled by our
import hook.
The importer has a mechanism that controls what types of modules we
allow to load. We call this loading behavior the "module load policy."
There are 3 settings:
* Only load C extensions
* Only load pure Python
* Try to load C and fall back to Python
An environment variable allows overriding this policy at run time. This
is mainly useful for developers and for performing actions against the
source checkout (such as installing), which require overriding the
default (strict) policy about requiring C extensions.
The default mode for now is to allow both. This isn't proper and is
technically backwards incompatible. However, it is necessary to
implement a sane patch series that doesn't break the world during
future bisections. The behavior will be corrected in future patch.
We choose the main mercurial/__init__.py module for this code out of
necessity: in a future world, if the custom module importer isn't
registered, we'll fail to find/import certain modules when running
from a pure installation. Without the magical import-time side-effects,
*any* importer of mercurial.* modules would be required to call a
function to register our importer. I'm not a fan of import time side
effects and I initially attempted to do this. However, I was foiled by
our own test harness, which has numerous `python` invoked scripts that
"import mercurial" and fail because the importer isn't registered.
Realizing this problem is probably present in random Python scripts
that have been written over the years, I decided that sacrificing
purity for backwards compatibility is necessary. Plus, if you are
programming Python, "import" should probably "just work."
It's worth noting that now that we have a custom module loader, it
would be possible to hook up demand module proxies at this level
instead of replacing __import__. We leave this work for another time,
if it's even desired.
This patch breaks importing in environments where Mercurial modules
are loaded from a zip file (such as py2exe distributions). This will
be addressed in a subsequent patch.
2015-12-04 08:37:01 +03:00
|
|
|
# We automagically register our custom importer as a side-effect of loading.
|
|
|
|
# This is necessary to ensure that any entry points are able to import
|
|
|
|
# mercurial.* modules without having to perform this registration themselves.
|
mercurial: implement a source transforming module loader on Python 3
The most painful part of ensuring Python code runs on both Python 2
and 3 is string encoding. Making this difficult is that string
literals in Python 2 are bytes and string literals in Python 3 are
unicode. So, to ensure consistent types are used, you have to
use "from __future__ import unicode_literals" and/or prefix literals
with their type (e.g. b'foo' or u'foo').
Nearly every string in Mercurial is bytes. So, to use the same source
code on both Python 2 and 3 would require prefixing nearly every
string literal with "b" to make it a byte literal. This is ugly and
not something mpm is willing to do at this point in time.
This patch implements a custom module loader on Python 3 that performs
source transformation to convert string literals (unicode in Python 3)
to byte literals. In effect, it changes Python 3's string literals to
behave like Python 2's.
In addition, the module loader recognizes well-known built-in
functions (getattr, setattr, hasattr) and methods (encode and decode)
that barf when bytes are used and prevents these from being rewritten.
This prevents excessive source changes to accommodate this change
(we would have to rewrite every occurrence of these functions passing
string literals otherwise).
The module loader is only used on Python packages belonging to
Mercurial.
The loader works by tokenizing the loaded source and replacing
"string" tokens if necessary. The modified token stream is
untokenized back to source and loaded like normal. This does add some
overhead. However, this all occurs before caching: .pyc files will
cache the transformed version. This means the transformation penalty
is only paid on first load.
As the extensive inline comments explain, the presence of a custom
source transformer invalidates assumptions made by Python's built-in
bytecode caching mechanism. So, we have to wrap bytecode loading and
writing and add an additional header to bytecode files to facilitate
additional cache validation when the source transformations
change in the future.
There are still a few things this code doesn't handle well, namely
support for zip files as module sources and for extensions. Since
Mercurial doesn't officially support Python 3 yet, I'm inclined to
leave these as to-do items: getting a basic module loading mechanism
in place to unblock further Python 3 porting effort is more important
than comprehensive module importing support.
check-py3-compat.py has been updated to ignore frames. This is
necessary because CPython has built-in code to strip frames from the
built-in importer. When our custom code is present, this doesn't work
and the frames get all messed up. The new code is not perfect. It
works for now. But once you start chasing import failures you find
some edge cases where the files aren't being printed properly. This
only burdens people doing future Python 3 porting work so I'm inclined
to punt on the issue: the most important thing is for the source
transforming module loader to land.
There was a bit of churn in test-check-py3-compat.t because we now
trip up on str/unicode/bytes failures as a result of source
transformation. This is unfortunate but what are you going to do.
It's worth noting that other approaches were investigated.
We considered using a custom file encoding whose decode() would
apply source transformations. This was rejected because it would
require each source file to declare its custom Mercurial encoding.
Furthermore, when changing the source transformation we'd need to
version bump the encoding name otherwise the module caching layer
wouldn't know the .pyc file was invalidated. This would mean mass
updating every file when the source transformation changes. Yuck.
We also considered transforming at the AST layer. However, Python's
ast module is quite gnarly and doing AST transforms is quite
complicated, even for trivial rewrites. There are whole Python packages
that exist to make AST transformations usable. AST transforms would
still require import machinery, so the choice was basically to
perform source-level, token-level, or ast-level transforms.
Token-level rewriting delivers the metadata we need to rewrite
intelligently while being relatively easy to understand. So it won.
General consensus seems to be that this approach is the best available
to avoid bulk rewriting of '' to b''. However, we aren't confident
that this approach will never be a future maintenance burden. This
approach does unblock serious Python 3 porting efforts. So we can
re-evaulate once more work is done to support Python 3.
2016-07-04 21:18:03 +03:00
|
|
|
if sys.version_info[0] >= 3:
|
|
|
|
_importercls = hgpathentryfinder
|
|
|
|
else:
|
|
|
|
_importercls = hgimporter
|
|
|
|
if not any(isinstance(x, _importercls) for x in sys.meta_path):
|
mercurial: implement import hook for handling C/Python modules
There are a handful of modules that have both pure Python and C
extension implementations. Currently, setup.py copies files from
mercurial/pure/*.py to mercurial/ during the install process if C
extensions are not available. This way, "import mercurial.X" will
work whether C extensions are available or not.
This approach has a few drawbacks. First, there aren't run-time checks
verifying the C extensions are loaded when they should be. This could
lead to accidental use of the slower pure Python modules. Second, the
C extensions aren't compatible with PyPy and running Mercurial with
PyPy requires installing Mercurial - you can't run ./hg from a source
checkout. This makes developing while running PyPy somewhat difficult.
This patch implements a PEP-302 import hook for finding and loading the
modules with both C and Python implementations. When a module with dual
implementations is requested for import, its import is handled by our
import hook.
The importer has a mechanism that controls what types of modules we
allow to load. We call this loading behavior the "module load policy."
There are 3 settings:
* Only load C extensions
* Only load pure Python
* Try to load C and fall back to Python
An environment variable allows overriding this policy at run time. This
is mainly useful for developers and for performing actions against the
source checkout (such as installing), which require overriding the
default (strict) policy about requiring C extensions.
The default mode for now is to allow both. This isn't proper and is
technically backwards incompatible. However, it is necessary to
implement a sane patch series that doesn't break the world during
future bisections. The behavior will be corrected in future patch.
We choose the main mercurial/__init__.py module for this code out of
necessity: in a future world, if the custom module importer isn't
registered, we'll fail to find/import certain modules when running
from a pure installation. Without the magical import-time side-effects,
*any* importer of mercurial.* modules would be required to call a
function to register our importer. I'm not a fan of import time side
effects and I initially attempted to do this. However, I was foiled by
our own test harness, which has numerous `python` invoked scripts that
"import mercurial" and fail because the importer isn't registered.
Realizing this problem is probably present in random Python scripts
that have been written over the years, I decided that sacrificing
purity for backwards compatibility is necessary. Plus, if you are
programming Python, "import" should probably "just work."
It's worth noting that now that we have a custom module loader, it
would be possible to hook up demand module proxies at this level
instead of replacing __import__. We leave this work for another time,
if it's even desired.
This patch breaks importing in environments where Mercurial modules
are loaded from a zip file (such as py2exe distributions). This will
be addressed in a subsequent patch.
2015-12-04 08:37:01 +03:00
|
|
|
# meta_path is used before any implicit finders and before sys.path.
|
mercurial: implement a source transforming module loader on Python 3
The most painful part of ensuring Python code runs on both Python 2
and 3 is string encoding. Making this difficult is that string
literals in Python 2 are bytes and string literals in Python 3 are
unicode. So, to ensure consistent types are used, you have to
use "from __future__ import unicode_literals" and/or prefix literals
with their type (e.g. b'foo' or u'foo').
Nearly every string in Mercurial is bytes. So, to use the same source
code on both Python 2 and 3 would require prefixing nearly every
string literal with "b" to make it a byte literal. This is ugly and
not something mpm is willing to do at this point in time.
This patch implements a custom module loader on Python 3 that performs
source transformation to convert string literals (unicode in Python 3)
to byte literals. In effect, it changes Python 3's string literals to
behave like Python 2's.
In addition, the module loader recognizes well-known built-in
functions (getattr, setattr, hasattr) and methods (encode and decode)
that barf when bytes are used and prevents these from being rewritten.
This prevents excessive source changes to accommodate this change
(we would have to rewrite every occurrence of these functions passing
string literals otherwise).
The module loader is only used on Python packages belonging to
Mercurial.
The loader works by tokenizing the loaded source and replacing
"string" tokens if necessary. The modified token stream is
untokenized back to source and loaded like normal. This does add some
overhead. However, this all occurs before caching: .pyc files will
cache the transformed version. This means the transformation penalty
is only paid on first load.
As the extensive inline comments explain, the presence of a custom
source transformer invalidates assumptions made by Python's built-in
bytecode caching mechanism. So, we have to wrap bytecode loading and
writing and add an additional header to bytecode files to facilitate
additional cache validation when the source transformations
change in the future.
There are still a few things this code doesn't handle well, namely
support for zip files as module sources and for extensions. Since
Mercurial doesn't officially support Python 3 yet, I'm inclined to
leave these as to-do items: getting a basic module loading mechanism
in place to unblock further Python 3 porting effort is more important
than comprehensive module importing support.
check-py3-compat.py has been updated to ignore frames. This is
necessary because CPython has built-in code to strip frames from the
built-in importer. When our custom code is present, this doesn't work
and the frames get all messed up. The new code is not perfect. It
works for now. But once you start chasing import failures you find
some edge cases where the files aren't being printed properly. This
only burdens people doing future Python 3 porting work so I'm inclined
to punt on the issue: the most important thing is for the source
transforming module loader to land.
There was a bit of churn in test-check-py3-compat.t because we now
trip up on str/unicode/bytes failures as a result of source
transformation. This is unfortunate but what are you going to do.
It's worth noting that other approaches were investigated.
We considered using a custom file encoding whose decode() would
apply source transformations. This was rejected because it would
require each source file to declare its custom Mercurial encoding.
Furthermore, when changing the source transformation we'd need to
version bump the encoding name otherwise the module caching layer
wouldn't know the .pyc file was invalidated. This would mean mass
updating every file when the source transformation changes. Yuck.
We also considered transforming at the AST layer. However, Python's
ast module is quite gnarly and doing AST transforms is quite
complicated, even for trivial rewrites. There are whole Python packages
that exist to make AST transformations usable. AST transforms would
still require import machinery, so the choice was basically to
perform source-level, token-level, or ast-level transforms.
Token-level rewriting delivers the metadata we need to rewrite
intelligently while being relatively easy to understand. So it won.
General consensus seems to be that this approach is the best available
to avoid bulk rewriting of '' to b''. However, we aren't confident
that this approach will never be a future maintenance burden. This
approach does unblock serious Python 3 porting efforts. So we can
re-evaulate once more work is done to support Python 3.
2016-07-04 21:18:03 +03:00
|
|
|
sys.meta_path.insert(0, _importercls())
|