bytes(default) was producing things like (default: \x00) when handed
non-bytes values such as 1, 10, or True. The man page generation would
apparently ignore these bytes and produce man pages that had the string
(default: ).
Details
- Reviewers
mjacob pulkit - Group Reviewers
hg-reviewers - Commits
- rHG1a4b9b602e54: py3: fix broken man page generation, it was generating `(default: NUL*)`
- Ran cd doc; python3 gendoc.py "hg.1.gendoc" and grepped for bad output
- Ran make deb, extracted the deb, manually inspected hg.1 file.
Diff Detail
- Repository
- rHG Mercurial
- Branch
- stable
- Lint
No Linters Available - Unit
No Unit Test Coverage
Event Timeline
doc/gendoc.py | ||
---|---|---|
90 | Isn’t bool(defaulttmpl) always true? | |
92 | I think it’s safer to use 'ascii' here. On Python 2, repr(default) is likely to return bytes and therefore will attempt to decode it with 'ascii' before encoding it with 'latin1'. In general, I don’t think it is guaranteed that the output is expected to be latin1-encoded. If we ever have non-ASCII default values, we should fail early instead of producing mojibake. An alternative to your code would be to use pycompat.bytestr. I don’t have a preference. An theoretical advantage is that is works correctly with bytearray, if we ever use it for default values. ;) |
doc/gendoc.py | ||
---|---|---|
90 | I assumed it wasn't and that this was a way of checking whether the translation had the string. But now that I'm reading it again, I think it's a different way of writing desc += _(b" (default: %s)") % bytes(default) if default else b"", so I've made this non-conditional. | |
92 | Yeah, now that I look closer, I was confused by the use of latin1 above. Switched this to stringutil.forcebytestr. |
doc/gendoc.py | ||
---|---|---|
92 | Sounds reasonable. |
Isn’t bool(defaulttmpl) always true?