[issue41706] docs: operator dunder (`__add__`, et al.) invocations described incorrectly
Change by William Chargin : -- keywords: +patch pull_requests: +21170 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22084 ___ Python tracker <https://bugs.python.org/issue41706> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41706] docs: operator dunder (`__add__`, et al.) invocations described incorrectly
New submission from William Chargin : The operator override dunder methods, like `__add__`, are described in the “Data model” docs here: <https://docs.python.org/3.10/reference/datamodel.html#object.__add__> Those docs say: > For instance, to evaluate the expression `x + y`, where `x` is an > instance of a class that has an `__add__()` method, `x.__add__(y)` is > called. But this is not correct: `x + y` always uses `type(x).__add__`, which may be different from `x.__add__` if `__add__` has been set directly on the instance. Demonstration: ``` class C: def __add__(self, other): return "from class" c = C() print(c + c) # prints "from class" c.__add__ = lambda other: "from instance" print(c.__add__(c)) # prints "from instance" print(type(c).__add__(c, c)) # prints "from class" print(c + c) # prints "from class"! ``` The same issue appears in the reversed operator dunder (`__radd__`, et al.) docs below. I have a patch that I can submit as a PR; just need a bpo number. -- assignee: docs@python components: Documentation messages: 376316 nosy: docs@python, wchargin priority: normal severity: normal status: open title: docs: operator dunder (`__add__`, et al.) invocations described incorrectly type: enhancement versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue41706> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18819] tarfile fills devmajor and devminor fields even for non-devices
William Chargin added the comment: My pleasure. Is there anything else that you need from me to close this out? It looks like the PR is approved and in an “awaiting merge” state, but I don’t have access to merge it. -- ___ Python tracker <https://bugs.python.org/issue18819> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39389] gzip metadata fails to reflect compresslevel
William Chargin added the comment: My pleasure; thanks for the triage and review! -- ___ Python tracker <https://bugs.python.org/issue39389> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18819] tarfile fills devmajor and devminor fields even for non-devices
William Chargin added the comment: I've just independently run into this and sent a patch as a pull request. Happily, once this is fixed, the output of `tarfile` is bit-for-bit compatible with the output of GNU `tar(1)`. PR: <https://github.com/python/cpython/pull/18080> -- nosy: +wchargin ___ Python tracker <https://bugs.python.org/issue18819> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18819] tarfile fills devmajor and devminor fields even for non-devices
Change by William Chargin : -- versions: +Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue18819> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18819] tarfile fills devmajor and devminor fields even for non-devices
Change by William Chargin : -- pull_requests: +17472 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18080 ___ Python tracker <https://bugs.python.org/issue18819> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39389] gzip metadata fails to reflect compresslevel
William Chargin added the comment: PR URL, for reference: <https://github.com/python/cpython/pull/18077> -- ___ Python tracker <https://bugs.python.org/issue39389> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39389] gzip metadata fails to reflect compresslevel
William Chargin added the comment: Sure, PR sent (pull_request17470). -- ___ Python tracker <https://bugs.python.org/issue39389> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39389] gzip metadata fails to reflect compresslevel
Change by William Chargin : -- keywords: +patch pull_requests: +17470 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/18077 ___ Python tracker <https://bugs.python.org/issue39389> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39389] gzip metadata fails to reflect compresslevel
William Chargin added the comment: (The commit reference above was meant to be git558f07891170, not a Mercurial reference. Pardon the churn; I'm new here. :-) ) -- ___ Python tracker <https://bugs.python.org/issue39389> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39389] gzip metadata fails to reflect compresslevel
Change by William Chargin : -- type: -> behavior ___ Python tracker <https://bugs.python.org/issue39389> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39389] gzip metadata fails to reflect compresslevel
New submission from William Chargin : The `gzip` module properly uses the user-specified compression level to control the underlying zlib stream compression level, but always writes metadata that indicates that the maximum compression level was used. Repro: ``` import gzip blob = b"The quick brown fox jumps over the lazy dog." * 32 with gzip.GzipFile("fast.gz", mode="wb", compresslevel=1) as outfile: outfile.write(blob) with gzip.GzipFile("best.gz", mode="wb", compresslevel=9) as outfile: outfile.write(blob) ``` Run this script, then run `wc -c *.gz` and `file *.gz`: ``` $ wc -c *.gz 82 best.gz 84 fast.gz 166 total $ file *.gz best.gz: gzip compressed data, was "best", last modified: Sun Jan 19 20:15:23 2020, max compression fast.gz: gzip compressed data, was "fast", last modified: Sun Jan 19 20:15:23 2020, max compression ``` The file sizes correctly reflect the difference, but `file` thinks that both archives are written at max compression. The error is that the ninth byte of the header in the output stream is hard-coded to `\002` at Lib/gzip.py:260 (as of 558f07891170), which indicates maximum compression. The correct value to indicate maximum speed is `\004`. See RFC 1952, section 2.3.1: <https://tools.ietf.org/html/rfc1952> Using GNU `gzip(1)` with `--fast` creates the same output file as the one emitted by the `gzip` module, except for two bytes: the metadata and the OS (the ninth and tenth bytes). -- components: Library (Lib) files: repro.py messages: 360268 nosy: wchargin priority: normal severity: normal status: open title: gzip metadata fails to reflect compresslevel versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 Added file: https://bugs.python.org/file48853/repro.py ___ Python tracker <https://bugs.python.org/issue39389> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com