This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author tim.peters
Recipients CuriousLearner, docs@python, mark.dickinson, martin.panter, ncoghlan, tim.peters, wolma
Date 2018-07-15.05:05:50
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1531631150.7.0.56676864532.issue29710@psf.upfronthosting.co.za>
In-reply-to
Content
Nick, that seems a decent compromise.  "Infinite string of sign bits" is how Guido & I both thought of it when the semantics of longs were first defined, and others in this report apparently find it natural enough too.  It also applies to all 6 operations in the table as-is.

It appears that

    a bit-width of ``1 + max(x.bit_length(), y.bit_length()``
    
only applies as-is to 3 (~ has only one operand, while the bit length of the RHS doesn't matter for << and >>).  Provided that's clarified, I'd only suggest inserting "at least" before "one extra sign extension bit" and after "a bit-width of".  That's a bridge between the "infinite" and "fixed-albeit-variable-width" views:  "plus 1" is the smallest approximation to infinity that works, but anything at least that large works too.
History
Date User Action Args
2018-07-15 05:05:50tim.peterssetrecipients: + tim.peters, mark.dickinson, ncoghlan, docs@python, martin.panter, wolma, CuriousLearner
2018-07-15 05:05:50tim.peterssetmessageid: <1531631150.7.0.56676864532.issue29710@psf.upfronthosting.co.za>
2018-07-15 05:05:50tim.peterslinkissue29710 messages
2018-07-15 05:05:50tim.peterscreate