-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make testsuite Python 2/3 compatible #7
Conversation
* Handling of unicode literal string prefix in doctests - partly avoided by an explicit conversion to `str` (usually for ASCII values) - test partly replaced by a comparison with a unicode literal string (usually for non ASCII values) * the "cgi" module of Python 3 and Python 2 behave differently for a two small "Content-Length" value Py 3: everything above this value is ignored; some data not processed Py 2: the value is ignored; all data processed To cope with this difference, the "http" function has been replaced by an auxiliary "http_request" function in some tests. "http_request" computes "Content-Length" correctly. * the test framework (--> "http", "browser") expects different input types for Python 3 and Python 2 Py 3: text Py 2: utf-8 encoded binary strings To cope with this difference, input values have been specified by explicit unicode literals (supported by both Python 3 and Python 2) and converted to the required type via an auxiliary "to_input" function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for resolving this issue. I like your code changes.
Additionally the following files should be changed resp. added:
setup.py
– the trove classifiers (This package should support the same versions as Zope)travis.yml
– so that the newly supported Python versions are tested, see z3c.wizard as an example how I would do it nowadaystox.ini
– This file should be added to be able to run the tests locally against multiple Python versions see z3c.table as an example..coveragerc
– This file should be added to configurecoverage
see z3c.table
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the work you put into this project.
…tegration uses an outdated version of `Persistence` (and `RestrictedPython`))
@icemac The Travis integration problems are likely caused by outdated versions of
However, I have no idea how I can force the Travis environment to use the correct versions. |
@d-maurer With these changes (see attached patch) locally Python 2.7 and 3.5 run successfully. (Newer Python versions fail with This most important point is the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This hint should make it possible to run successfully on travis ci.
@icemac Thank you: with the |
….7 is not installed; attempting download` and the download fails
…version - use explicitely Python 3.7 from `xenial`
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM with some minor suggestions.
@d-maurer Thank you very much! |
Released to PyPI: https://pypi.org/project/five.formlib/2.1/ |
Handling of unicode literal string prefix in doctests
str
(usually for ASCII values)the "cgi" module of Python 3 and Python 2 behave differently for a two small "Content-Length" value
Py 3: everything above this value is ignored; some data not processed
Py 2: the value is ignored; all data processed
To cope with this difference, the "http" function has been replaced by an auxiliary "http_request" function in some tests. "http_request" computes "Content-Length" correctly.
the test framework (--> "http", "browser") expects different input types for Python 3 and Python 2
Py 3: text
Py 2: utf-8 encoded binary strings
To cope with this difference, input values have been specified by explicit unicode literals (supported by both Python 3 and Python 2) and converted to the required type via an auxiliary "to_input" function.