[issue26800] Don't accept bytearray as filenames part 2

Changes by Serhiy Storchaka : -- resolution: -> fixed stage: commit review -> resolved status: open -> closed ___ Python tracker

[issue26800] Don't accept bytearray as filenames part 2

Roundup Robot added the comment: New changeset 1e01ca34a42c by Serhiy Storchaka in branch 'default': Issue #26800: Undocumented support of general bytes-like objects https://hg.python.org/cpython/rev/1e01ca34a42c -- ___ Python tracker

[issue26800] Don't accept bytearray as filenames part 2

Brett Cannon added the comment: Assigning to Serhiy to apply since Larry doesn't care and I already reviewed the patch. -- assignee: larry -> serhiy.storchaka stage: patch review -> commit review ___ Python tracker

[issue26800] Don't accept bytearray as filenames part 2

Brett Cannon added the comment: Serhiy's patch LGTM. -- nosy: +brett.cannon ___ Python tracker ___ ___

[issue26800] Don't accept bytearray as filenames part 2

Serhiy Storchaka added the comment: Ping. -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue26800] Don't accept bytearray as filenames part 2

Serhiy Storchaka added the comment: Here is a patch that deprecates support of general bytes-like objects in os functions. -- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file43336/path_converter-deprecate-buffer.patch

[issue26800] Don't accept bytearray as filenames part 2

Roundup Robot added the comment: New changeset 3fb0f9a0b195 by Guido van Rossum in branch 'default': Rip out the promotion from bytearray/memoryview to bytes. See http://bugs.python.org/issue26800. https://hg.python.org/peps/rev/3fb0f9a0b195 -- nosy: +python-dev

[issue26800] Don't accept bytearray as filenames part 2

Guido van Rossum added the comment: Sigh, I was wrong, not only does mypy promote bytearray to bytes, it actually depends on this in its own code. Not for filenames, but for a regex match. It reads the source into a bytearray, and then passes that to something that uses regex matches (which *do*

[issue26800] Don't accept bytearray as filenames part 2

Guido van Rossum added the comment: OK, it isn't worth fighting for. I will update PEP 484. It seems mypy doesn't support the special treatment bytearray anyway. For posterity, the reason I thought that bytearray should be accepted is not that bytearray is better in any way, just that sometimes

[issue26800] Don't accept bytearray as filenames part 2

STINNER Victor added the comment: I'm really sceptical that anyone really use bytearray for filenames in Python. I'm quite sure that most functions fail with bytearray. Do you have an example of application using bytearray? What's the point of using bytearray? To limit memory copy and

[issue26800] Don't accept bytearray as filenames part 2

Serhiy Storchaka added the comment: The os.path module and os.fsdecode() don't support bytearray paths. Should we add bytearray support? This will complicate and slowdown os.path functions which often are used multiple times in tight loops. Correspondingly, many Python implemented functions

[issue26800] Don't accept bytearray as filenames part 2

Guido van Rossum added the comment: OK, I actually agree with you on memoryview and and other types that support the buffer view. I will update PEP 484 to exclude memoryview. But I think bytearray has a special role and purose, and as much as possible it needs to be accepted in places that

[issue26800] Don't accept bytearray as filenames part 2

Serhiy Storchaka added the comment: Side comment about "bytes-like" and "byte string". As for language from PEP 484, I think it is too permissive. bytes and bytearray have are "bytes strings" because they are not only sequences of bytes, but have a lot of str-like methods: lower(), split(),

[issue26800] Don't accept bytearray as filenames part 2

Guido van Rossum added the comment: I'm a little bit worried about removing support for bytearray in these cases. It used to be quite easy to support bytes and bytearray (just say you support the buffer API), and I even added language to PEP 484 suggesting that type checkers should consider

[issue26800] Don't accept bytearray as filenames part 2

STINNER Victor added the comment: bytearray is designed for performance. I don't think that the code creating a filename can be a bottleneck in an application. -- ___ Python tracker

[issue26800] Don't accept bytearray as filenames part 2

Larry Hastings added the comment: I did the path_converter change. IIRC some functions supported bytearray, some did not, and in my quest for consistency I took the superset of functionality and supported bytearray for everything. Sounds to me like bytearray support should be dropped, but

[issue26800] Don't accept bytearray as filenames part 2

Philip Jenvey added the comment: Thanks Serhiy, I did not see the python-dev thread. This coincidentally came up recently in pypy3. +1 for some kind of deprecation period needed -- ___ Python tracker

[issue26800] Don't accept bytearray as filenames part 2

Serhiy Storchaka added the comment: In the light of issue8485 this looks as a bug. Thank you for investigating this Philip. I already raised this issue on Python-Dev less than a week ago [1], and only Victor had answered, thus we can assume that the consensus about bytes-like paths is not

[issue26800] Don't accept bytearray as filenames part 2

New submission from Philip Jenvey: Basically a reopen of the older issue8485 with the same name. It was decided there to drop support for bytearray filenames -- partly because of the complexity of handling buffers but it was also deemed to just not make much sense. This regressed or crept