Eryk Sun <eryk...@gmail.com> added the comment:
> The Documentation component is for issues that only change the docs That's not clear in the triaging guide for the multi-select component field. (However, it is clearly stated as such for the GitHub PR label "type-documentation".) If that's really the case, then I'll manually nosy the docs team in cases such as this. When wording is disputed and needs to be clarified, I want an expert at documentation to propose or review the change. > Adding 'Documentation' amounts to rejecting this patch or anything > else that changes the code. That was not my intent. I accepted Tom's position that "string" means a C string, which must be null-terminated. So I added the "Lib" tag and left it as a "behavior" issue instead of changing it to "enhancement". I'm concerned that the old c_buffer() function is defined to call create_string_buffer(), and it's not officially deprecated in the docs or the source code. (There's a commented-out deprecation warning.) A related concern is that the documentation says that the length of a byte-string initializer should not be used if the size is specified, which allows creating a character-array that's not null-terminated. If it raises a ValueError in this case, the wording should be clear that the value of `size` must be large enough to set the initial value as a null-terminated string. I also would want c_buffer() to get a separate implementation in this case. If accepted, create_unicode_buffer(init, size) should also be changed to require that init is set as a null-terminated string. ---------- components: +Library (Lib) priority: low -> normal stage: needs patch -> patch review versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.6 _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue24823> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
