[issue20895] Add bytes.empty_buffer and deprecate bytes(17) for the same purpose

Changes by Terry J. Reedy : -- resolution: -> out of date stage: -> resolved ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue20895] Add bytes.empty_buffer and deprecate bytes(17) for the same purpose

Ethan Furman added the comment: Superseded by PEP467. -- status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue20895] Add bytes.empty_buffer and deprecate bytes(17) for the same purpose

Terry J. Reedy added the comment: May we close this as superceded by pep467? -- ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue20895] Add bytes.empty_buffer and deprecate bytes(17) for the same purpose

Nick Coghlan added the comment: Under the name "from_len", this is now part of a larger proposal to improve the consistency of the binary APIs: http://www.python.org/dev/peps/pep-0467/ -- ___ Python tracker __

[issue20895] Add bytes.empty_buffer and deprecate bytes(17) for the same purpose

Nick Coghlan added the comment: The fill() name makes more sense for the bytearray variant, it is just provided on bytes as well for consistency. As Serhiy notes above, the current behaviour is almost certainly just a holdover from the original "mutable bytes" design that didn't survive into t

[issue20895] Add bytes.empty_buffer and deprecate bytes(17) for the same purpose

R. David Murray added the comment: Also, to me 'fill' implies something is being filled, not that something is being created. -- ___ Python tracker ___ _

[issue20895] Add bytes.empty_buffer and deprecate bytes(17) for the same purpose

Josh Rosenberg added the comment: Why would we need bytes.fill(length, value)? Is b'\xVV' * length (or if value is a variable containing int, bytes((value,)) * length) unreasonable? Similarly, bytearray(b'\xVV) * length or bytearray((value,)) * length is both Pythonic and performant. Most sequ

[issue20895] Add bytes.empty_buffer and deprecate bytes(17) for the same purpose

Nick Coghlan added the comment: Bringing over Barry's suggestion from the current python-ideas thread [1]: @classmethod def fill(cls, length, value=0): # Creates a bytes of given length with given fill value [1] https://mail.python.org/pipermail/python-ideas/2014-March/027305.ht

[issue20895] Add bytes.empty_buffer and deprecate bytes(17) for the same purpose

Changes by Barry A. Warsaw : -- nosy: +barry ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue20895] Add bytes.empty_buffer and deprecate bytes(17) for the same purpose

Changes by Martin Panter : -- nosy: +vadmium ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue20895] Add bytes.empty_buffer and deprecate bytes(17) for the same purpose

Ethan Furman added the comment: Python 2.7.3 (default, Sep 26 2012, 21:51:14) [GCC 4.7.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. --> bytes(5) '5' --> bytearray(5) bytearray(b'\x00\x00\x00\x00\x00') --

[issue20895] Add bytes.empty_buffer and deprecate bytes(17) for the same purpose

Serhiy Storchaka added the comment: AFAIK, bytes(int) is a remnant from times when bytes was mutable. Then bytes was split to non-mutable bytes and mutable bytearray and this constructor was forgotten. I'm +0 for deprecation. -- ___ Python tracker

[issue20895] Add bytes.empty_buffer and deprecate bytes(17) for the same purpose

Ethan Furman added the comment: I'm inclined to leave it open while I do the suggested research. Thanks for the tips, Terry, and the numbers, Josh. -- ___ Python tracker ___ ___

[issue20895] Add bytes.empty_buffer and deprecate bytes(17) for the same purpose

Josh Rosenberg added the comment: 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 proce

[issue20895] Add bytes.empty_buffer and deprecate bytes(17) for the same purpose

Terry J. Reedy added the comment: 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 silentl

[issue20895] Add bytes.empty_buffer and deprecate bytes(17) for the same purpose

Josh Rosenberg added the comment: I would think the argument for deprecation is that usually, people type bytes(7) or bytes(somesmallintvalue) expecting to create a length one bytes object using that value (happens by accident if you iterate a bytes object and forget it's an iterable of ints,

[issue20895] Add bytes.empty_buffer and deprecate bytes(17) for the same purpose

R. David Murray added the comment: I don't have a strong opinion on this, but I think you are going to have to articulate a good use/usability case for the deprecation. I'm sure this is used in the wild, and we don't just gratuitously break things :) -- nosy: +r.david.murray

[issue20895] Add bytes.empty_buffer and deprecate bytes(17) for the same purpose

Serhiy Storchaka added the comment: Class method is not needed. This is just b'\0' * 7. -- nosy: +serhiy.storchaka ___ Python tracker ___

[issue20895] Add bytes.empty_buffer and deprecate bytes(17) for the same purpose

New submission from Ethan Furman: `bytes` is a list of integers. Passing a single integer to `bytes()`, as in: --> bytes(7) b'\x00\x00\x00\x00\x00\x00\x00' results in a bytes object containing that many zeroes. I propose that this behavior be deprecated for eventual removal, and a class