bpo-29710: Clarify documentation for Bitwise binary operation #1691
Conversation
|
@CuriousLearner, thanks for your PR! By analyzing the history of the files in this pull request, we identified @terryjreedy, @birkenfeld and @ncoghlan to be potential reviewers. |
|
Hey @terryjreedy , @birkenfeld & @ncoghlan ! This patch is pending for a while. Can you please take some time to review this? :) |
| @@ -441,6 +440,11 @@ Notes: | |||
| A right shift by *n* bits is equivalent to division by ``pow(2, n)`` without | |||
| overflow check. | |||
|
|
|||
| (4) | |||
There was a problem hiding this comment.
Forgot to add references to the new footnote?
There was a problem hiding this comment.
@vadmium How should I reference it? Is this what is required?
index 5fa3ca10fd..40129f0037 100644
--- a/Doc/library/stdtypes.rst
+++ b/Doc/library/stdtypes.rst
@@ -400,7 +400,7 @@ Bitwise Operations on Integer Types
operator: >>
Bitwise operations only make sense for integers. Negative numbers are treated
-as their 2's complement value.
+as their 2's complement value (4).
There was a problem hiding this comment.
If you are trying to follow Nick’s suggestion (move the note about negative numbers to a numbered footnote in the table), I think he was suggesting adding (4) to the table that the other three footnotes relate to, specifically to each of the first three rows for x | y, x ^ y, and x & y. These are bitwise binary operations and they define x and y.
However I am not enthusiastic about the new text; see my comments in the bug thread.
There was a problem hiding this comment.
So, what do you think about Nick's suggestion, where he included Mark's suggestion as well:
Each bitwise operation has the same result as though carried out in two's complement using a bit-width that's large enough to represent the inputs. ("Large enough" for this purpose is ``1 + max(x.bit_length(), y .bit_length()``, with the extra bit being needed to handle sign extension appropriately)
|
@vadmium @brettcannon Is there anything I can do here to get this merged? |
|
A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated. Once you have made the requested changes, please leave a comment on this pull request containing the phrase |
* master: (2633 commits) bpo-34087: Fix buffer overflow in int(s) and similar functions (pythonGH-8274) bpo-34108: Fix double carriage return in 2to3 on Windows (python#8271) bpo-4260: Document that ctypes.xFUNCTYPE are decorators (pythonGH-7924) bpo-33723: Fix test_time.test_thread_time() (pythonGH-8267) bpo-33967: Remove use of deprecated assertRaisesRegexp() (pythonGH-8261) bpo-34080: Fix a memory leak in the compiler. (pythonGH-8222) Enable GUI testing on Travis Linux builds via Xvfb (pythonGH-7887) bpo-23927: Make getargs.c skipitem() skipping 'w*'. (pythonGH-8192) bpo-33648: Remove PY_WARN_ON_C_LOCALE (pythonGH-7114) bpo-34092, test_logging: increase SMTPHandlerTest timeout (pythonGH-8245) Simplify __all__ in multiprocessing (pythonGH-6856) bpo-34083: Update dict order in Functional HOWTO (pythonGH-8230) Doc: Point to Simple statements section instead of PEP (pythonGH-8238) bpo-29442: Replace optparse with argparse in setup.py (pythonGH-139) bpo-33597: Add What's New for PyGC_Head (pythonGH-8236) Dataclasses: Fix example on 30.6.8, add method should receive a list rather than an integer. (pythonGH-8038) Fix documentation for input and output tutorial (pythonGH-8231) bpo-34009: Expand on platform support changes (pythonGH-8022) Factor-out two substantially identical code blocks. (pythonGH-8219) bpo-34031: fix incorrect usage of self.fail in two tests (pythonGH-8091) ...
|
@ncoghlan I've made the changes as suggested by you. Can you please have a look now? :) |
|
@CuriousLearner do note that the bot requests you say "I have made the requested changes; please review again" in order to signal to @ncoghlan and other core devs that you are ready to have this PR looked at again. |
|
I have made the requested changes; please review again |
|
Thanks for making the requested changes! @ncoghlan: please review the changes made to this pull request. |
|
Thanks @CuriousLearner for the PR, and @ncoghlan for merging it 🌮🎉.. I'm working now to backport this PR to: 3.6, 3.7. |
…GH-1691) Mathematically, bitwise operations on integers behave as if there were an infinite number of sign bits. Pragmatically, that gives the same answer as using one extra sign bit for the bitwise logical operations. (cherry picked from commit b4bc5ca) Co-authored-by: Sanyam Khurana <[email protected]>
|
GH-8508 is a backport of this pull request to the 3.7 branch. |
…GH-1691) Mathematically, bitwise operations on integers behave as if there were an infinite number of sign bits. Pragmatically, that gives the same answer as using one extra sign bit for the bitwise logical operations. (cherry picked from commit b4bc5ca) Co-authored-by: Sanyam Khurana <[email protected]>
|
GH-8509 is a backport of this pull request to the 3.6 branch. |
Mathematically, bitwise operations on integers behave as if there were an infinite number of sign bits. Pragmatically, that gives the same answer as using one extra sign bit for the bitwise logical operations. (cherry picked from commit b4bc5ca) Co-authored-by: Sanyam Khurana <[email protected]>
Mathematically, bitwise operations on integers behave as if there were an infinite number of sign bits. Pragmatically, that gives the same answer as using one extra sign bit for the bitwise logical operations. (cherry picked from commit b4bc5ca) Co-authored-by: Sanyam Khurana <[email protected]>
Resolves http://bugs.python.org/issue29710
clarify documentation for bitwise binary operators.
https://bugs.python.org/issue29710