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 terry.reedy
Recipients ethan.furman, josh.r, r.david.murray, serhiy.storchaka, terry.reedy
Date 2014-03-14.22:13:16
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1394835196.99.0.151910326694.issue20895@psf.upfronthosting.co.za>
In-reply-to
Content
I agree with Serhiy that the method is not needed in any case.

I was about to post the same missing rationale: people misunderstand 'bytes(7)' and write it expecting to get bytes([7]) == b(\x07'), so it would be better to make bytes(7) raise instead of silently accepting a buggy usage.  I was thinking that one rationale for bytes(n) might be that it is faster than b'\0' * n. Since Josh claimed the contrary, I tried to test with timeit.repeat (both console and Idle) and got this error message
  TypeError: source code string cannot contain null bytes
Both eval and compile emit this message. So it seems that one justification for bytes(n) is to avoid putting null bytes in source strings.

I think this issue should be closed. Deprecation ideas should really be posted of python-ideas and ultimately pydev for discussion and approval.

If Ethan wants to pursue the idea, he should research the design discussions for bytes() (probably on the py3k list) and whether Guido directly approved of bytes(n) or if someone else 'snuck' it in after the initial approval.
History
Date User Action Args
2014-03-14 22:13:17terry.reedysetrecipients: + terry.reedy, r.david.murray, ethan.furman, serhiy.storchaka, josh.r
2014-03-14 22:13:16terry.reedysetmessageid: <1394835196.99.0.151910326694.issue20895@psf.upfronthosting.co.za>
2014-03-14 22:13:16terry.reedylinkissue20895 messages
2014-03-14 22:13:16terry.reedycreate