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 anon, hct, mark.dickinson, meador.inge, pitrou, rhettinger, serhiy.storchaka, tim.peters, vstinner
Date 2013-12-09.22:40:18
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1386628819.38.0.960172055635.issue19915@psf.upfronthosting.co.za>
In-reply-to
Content
@HCT, see http://bugs.python.org/issue19915#msg205713 for what's "semantically wrong".  Ints are not arrays - slicing is unnatural.

The point about error checking is that if this were supported via slicing notation, then the _helpful_ exceptions of the form, e.g.,

    TypeError: 'int' object has no attribute '__getitem__'

would no longer occur for code like

    myarray[1:12]

where `myarray` is mistakenly bound to an integer.  We always lose something when assigning a meaning to an operation that formerly raised an exception.

About:

> calling a function is way more expensive than doing
> bit shift and/or AND operation

read the very first message in this issue.  There is no upper bound on how expensive bit shifts and logical operations can be on Python integers:  they can take time proportional to the number of bits.  But a function to extract a bit can be written internally to require small constant time, independent of the number of bits in the integer.  At least that's true for CPython ints >= 0; it may well take longer for negative CPython ints in some cases.

If speed on small ints is your primary concern, by all means continue to fiddle the bits by hand ;-)
History
Date User Action Args
2013-12-09 22:40:19tim.peterssetrecipients: + tim.peters, rhettinger, mark.dickinson, pitrou, vstinner, meador.inge, serhiy.storchaka, hct, anon
2013-12-09 22:40:19tim.peterssetmessageid: <1386628819.38.0.960172055635.issue19915@psf.upfronthosting.co.za>
2013-12-09 22:40:19tim.peterslinkissue19915 messages
2013-12-09 22:40:18tim.peterscreate