tahoe-lafs/trac-2024-07-25
2
0
Issues 1.1k Wiki Activity

[Imported from Trac: page Python3, version 15]

itamarst 2020-09-11 18:11:04 +00:00
parent 0bfdfb8e55
commit d614b4cdac
1 changed files with 9 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

18
Python3.md

@ -61,15 +61,6 @@ if PY2:
from future.builtins import filter, map, zip, ascii, chr, hex, input, next, oct, open, pow, round, super, bytes, dict, list, object, range, str, max, min # noqa: F401 from future.builtins import filter, map, zip, ascii, chr, hex, input, next, oct, open, pow, round, super, bytes, dict, list, object, range, str, max, min # noqa: F401
``` ```
### When things get complicated
In practice, the methodology above is somewhat idealized: a sufficiently important module might have multiple test files, and might not be easily splittable.
This is where the test ratchet comes in.
The test ratchet ensures that once a specific test is marked as passing in Python 3, it can't stop passing on Python 3.
As a result, progress in porting need not involve a module being fully ported in one PR, or all tests being made to pass.
Thus, complex modules can be ported over multiple PRs by just increasing the list of passing tests in each PR, and then only marking the module as fully ported in the final PR.
This adds builtins that match Python 3's semantics. The `#noqa: F401` keeps flake8/pyflakes from complaining about unused imports. We do unused imports so that people changing code later don't have to manually check if `map()` is old style or new style. This adds builtins that match Python 3's semantics. The `#noqa: F401` keeps flake8/pyflakes from complaining about unused imports. We do unused imports so that people changing code later don't have to manually check if `map()` is old style or new style.
**Fourth**, manually review the code. Futureize is nice, but it very definitely doesn't catch everything, or it makes wrong decisions. **Fourth**, manually review the code. Futureize is nice, but it very definitely doesn't catch everything, or it makes wrong decisions.
@ -96,6 +87,15 @@ One of them is the `bytes` objects:
Leaking Future objects (newints, new dicts, new bytes) in module API can break existing code on Python 2. So need to be careful not to do that. For that reason int isn't in the suggested `from builtins import ...` list above. Leaking Future objects (newints, new dicts, new bytes) in module API can break existing code on Python 2. So need to be careful not to do that. For that reason int isn't in the suggested `from builtins import ...` list above.
## When ports get harder due to spaghetti dependencies
As the port progresses, the simple "port module + its test module" gets difficult, since everything ends up depending on everything else.
Here's on way to approach this:
1. Port _only_ the test module. This involves many fixes to lots of other modules, but they are not officially ported, they're just inched along just enough to make the tests pass. Since the test module is officially ported, regressions to the Python 3 port still are prevented.
2. Then, port the corresponding module.
## Other notes ## Other notes
If you just want to run the tests from the explicitly ported test modules, you can do `python -m allmydata.util._python3`. If you just want to run the tests from the explicitly ported test modules, you can do `python -m allmydata.util._python3`.