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 josh.r
Recipients ethan.furman, josh.r, r.david.murray, serhiy.storchaka, terry.reedy
Date 2014-03-14.22:23:54
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1394835834.59.0.682820485058.issue20895@psf.upfronthosting.co.za>
In-reply-to
Content
Terry: You forgot to use a raw string for your timeit.repeat check, which is why it blew up. It was evaluating the \0 when you defined the statement string itself, not the contents. If you use r'b"\0" * 7' it works just fine by deferring backslash escape processing until the string is actually eval-ed, rather than when you create the string.

For example, on my (admittedly underpowered) laptop (Win7 x64, Py 3.3.0 64-bit):

>>> min(timeit.repeat(r'b"\0" * 7'))
0.07514287752866267
>>> min(timeit.repeat(r'bytes(7)'))
0.7210309422814021
>>> min(timeit.repeat(r'b"\0" * 7000'))
0.8994351749659302
>>> min(timeit.repeat(r'bytes(7000)'))
2.06750710129117

For a short bytes, the difference is enormous (as I suspected, the lookup of bytes dominates the runtime). For much longer bytes, it's still winning by a lot, because the cost of having the short literal first, then multiplying it, is still trivial next to the lookup cost.

P.S. I made a mistake: str does accept an int argument (obviously), but it has completely different meaning.
History
Date User Action Args
2014-03-14 22:23:54josh.rsetrecipients: + josh.r, terry.reedy, r.david.murray, ethan.furman, serhiy.storchaka
2014-03-14 22:23:54josh.rsetmessageid: <1394835834.59.0.682820485058.issue20895@psf.upfronthosting.co.za>
2014-03-14 22:23:54josh.rlinkissue20895 messages
2014-03-14 22:23:54josh.rcreate