Using decorator can localize changes for adding (or removing) a
template filter function in source code.
This patch also removes leading ":FILTER:" part in help document of
each filters, because using templatefilter makes it useless.
This patch uses not 'filter' but 'templatefilter' as a decorator name,
because the former name hides Python built-in one, even though the
latter is a little redundant in 'templatefilters.py'.
Python 3's hex() insists on operating on bytes. This patch gives
it what it wants.
'' and b'' in Python 2 are equivalent, so this has no impact on
Python 2.
All of mercurial.* is now using absolute_import. Most of
mercurial.* is able to ast parse with Python 3. The next big
hurdle is being able to import modules using Python 3.
This patch adds testing of hgext.* and mercurial.* module imports
in Python 3. As the new test output shows, most modules can't
import under Python 3. However, many of the failures are due
to a common problem in a highly imported module (e.g. the bytes vs
str issue in node.py).
Previously, test-check-py3-compat.t parsed Python files with Python 2
and looked for known patterns that are incompatible with Python 3.
Now that we have a mechanism for invoking Python 3 interpreters from
tests, we can expand check-py3-compat.py and its corresponding .t
test to perform an additional AST parse using Python 3.
As the test output shows, we identify a number of new parse failures
on Python 3. There are some redundant warnings for missing parentheses
for the print function. Given the recent influx of patches around
fixing these, the redundancy shouldn't last for too long.
Actually since Python 2.3, there is some way to turn top level package into
"namespace package" so that multiple subpackage installed in different part of
the path can still be imported transparently. This feature was previously
thought (at least by myself) to be only provided by some setuptool black magic.
Turning hgext into such namespace package allows third extensions to install
themselves inside the "hgext" namespace package to avoid polluting the global
python module namespace. They will now be able to do so without making it a pain
to use a Mercurial "installed" in a different way/location than these
extensions.
The only constrains is that the extension ship a 'hgext/__init__.py' containing
the same call to 'pkgutil.extend_path' and nothing else. This seems realistic.
The main question that remains is: should we introduce a dedicated namespace for
third party extension (hgext3rd?) to make a clearer distinction between what is
officially supported and what is not? If so, this will be introduced in a follow
up patch.
In preparation for the filesystem monitor extension, include the pywatchman
library. The fbmonitor extension relies on this library to communicate with
the Watchman service. The library is BSD licensed and is taken from
https://github.com/facebook/watchman/tree/master/python.
This package has not been updated to mercurial code standards.
