Similar to the recent adoption of Black. isort is a Python utility to
sort imports alphabetically and automatically separate into sections. By
using isort, contributors can quickly and automatically conform to the
projects style without thinking. Just let the tool do it.
Uses the configuration recommended by the Black to avoid conflicts of
style.
Rewrite TestImageQt.test_deprecated to no rely on import order.
With the introduction and use of pytest, it is simple and easy to
execute specific tests in isolation through documented command line
arguments. Either by specifying the module path or through the `-k
EXPRESSION` argument. There is no longer any need to provide the
boilerplate:
if __name__ == '__main__':
unittest.main()
To every test file. It is simply noise.
The pattern remains in test files that aren't named with `test_*` as
those files are not discovered and executed by pytest by default.
The previous test configuration made it difficult to run a single test
with the pytest CLI. There were two major issues:
- The Tests directory was not a package. It now includes a __init__.py
file and imports from other tests modules are done with relative
imports.
- setup.cfg always specified the Tests directory. So even if a specific
test were specified as a CLI arg, this configuration would also always
include all tests. This configuration has been removed to allow
specifying a single test on the command line.
Contributors can now run specific tests with a single command such as:
$ tox -e py37 -- Tests/test_file_pdf.py::TestFilePdf.test_rgb
This makes it easy and faster to iterate on a single test failure and is
very familiar to those that have previously used tox and pytest.
When running tox or pytest with no arguments, they still discover and
runs all tests in the Tests directory.
* added thresh option and test
* fixed up, test works and passes
* Update test_imagedraw.py
* Update test_imagedraw.py
* Update ImageDraw.py
* removed pypy skip decorator from thresh test
* Update ImageDraw.py
This tests are designed to guarantee that the wide lines behave exactly
like normal lines drawn with the Bresenham's algorithm.
This tests are somewhat subjective since this is non-defined behavior,
but I think that mimic the Bresenham's algorithm is reliable enough.
Currently the horizontal version of this test **fail**.
Only the oblique 3 pixels wide lines are defined:
* The oblique 2 pixels wide lines are somewhat hard to define.
* To define the oblique lines wider than 3 pixels we neet to define
first how the oblique lines should expand their width (realistic or
exact).
Notice that the expansion of the line width depends on the order of the
points:
* If the bigger axis value is provided as the *second* point the line
expand first to the *positive* side of the axis.
* If the bigger axis value is provided as the *first* point the line
expand first to the *negative* side of the axis.
* If the line's width is odd this doesn't matter, as the line will
expand the same amount to both sides.
This behavior should be consistent in both horizontal and vertical lines.
This is Christoph Gohlke's test suite from his personal PIL package found
at http://www.lfd.uci.edu/~gohlke/pythonlibs/.
This is just to bring it in as a separate commit. Future commits will align
it with Pillow.
