[issue24000] More fixes for the Clinic mapping of converters to format units
Roundup Robot added the comment: New changeset 36d5e04b6cfa by Larry Hastings in branch 'default': Issue #24000: Improved Argument Clinic's mapping of converters to legacy https://hg.python.org/cpython/rev/36d5e04b6cfa -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24000 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24000] More fixes for the Clinic mapping of converters to format units
Larry Hastings added the comment: I think this is a definite improvement, so I've checked it in so I can move on. If you guys still want to talk about it, we can still change it before we hit beta. -- resolution: - fixed stage: patch review - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24000 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24000] More fixes for the Clinic mapping of converters to format units
Larry Hastings added the comment: Here's a freshened version of the patch. I updated the Clinic HOWTO. Serhiy: You're right, length and zeroes always have the same value. Would you ever want length without allowing zeroes? Like, in the future, would we ever want str(length=True) so we're passed in the length but we still don't want to allow zeroes? -- Added file: http://bugs.python.org/file39288/larry.one.more.clinic.format.unit.map.cleanup.4.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24000 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24000] More fixes for the Clinic mapping of converters to format units
Serhiy Storchaka added the comment: I would say it is very unlikely. In any case, if we have a pointer and a length, we always can check for zeros after parsing. May be rename the str converter to pchar and the Py_UNICODE converter to pwchar? Usually the converter is named by C type, not Python type. y and y# even don't accept str. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24000 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24000] More fixes for the Clinic mapping of converters to format units
Larry Hastings added the comment: I have no interest in naming str to pchar. Yes, *most* of the other converters are named after the C type they translate to. But so far converter names doesn't mention whether or not they represent pointers to types--it's object, not pobject, it's PyBytesObject, not pPyBytesObject. That suggests the name char for the converter. But we've already got a char, and it would be confusing to use that one converter for both chars (small ints / single characters) and strings. Adding p in front is not a convention we've ever used. The word pchar does not appear in the Python source tree. So the name pchar has no mnemonic value. If I were to follow your advice, I should prefer the name char_star. But now we're using nine letters for what is almost certainly the most common converter. And, again, the generic converter for objects is called object, I do not propose to rename it to object_star. So this converter's name would be an exception to the rule. But then again, C strings themselves are an exception to the rule. They're not a built-in type as much as they are a *convention*. So any name we give it will ultimately be something of a compromise. And as compromises go str is great. So far nobody has been confused by it. It's short, and universally, instantly clear as to its meaning. Furthermore, converters don't actually represent a C type. They represent a *mapping*, from a Python type (or types) to a single C type. So while it's a useful and productive convention to name converters after the type they convert to, it's hardly mandatory. And it would be a shame to squander clarity in service to a needless consistency. p.s. If we hold ourselves to this firm ideal, where every converter is named after its C type, what should we call the bool converter? What should we call the self converter? What should you call your proposed boolint converter? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24000 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24000] More fixes for the Clinic mapping of converters to format units
Larry Hastings added the comment: Here's an updated patch where I've removed the length parameter to converters, instead relying solely on the zeroes parameter. -- Added file: http://bugs.python.org/file39289/larry.one.more.clinic.format.unit.map.cleanup.5.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24000 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24000] More fixes for the Clinic mapping of converters to format units
Larry Hastings added the comment: As for str doesn't even accept str for y and y#, the name str is not for the Python type, it's for the C type. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24000 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24000] More fixes for the Clinic mapping of converters to format units
Serhiy Storchaka added the comment: Why not left the length parameter instead? First, current code uses length. Second, the main effect from C side is that an argument is a pair (pointer, length), not just a pointer. Third, currently everywhere in Python documentation and error messages the used term is null character/byte, so if left the zeros parameter, it should be renamed to allow_nulls or allow_nuls. Fourth, y# needs zeros=True for distinguish from y, but y* allows nulls and has no the zeros parameter. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24000 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24000] More fixes for the Clinic mapping of converters to format units
Serhiy Storchaka added the comment: May be string, or data, or buffer would be better names? str looks as Python type. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24000 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24000] More fixes for the Clinic mapping of converters to format units
Larry Hastings added the comment: I don't think those are better names. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24000 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24000] More fixes for the Clinic mapping of converters to format units
Larry Hastings added the comment: I don't know why you're bringing up previous versions of Python. The clinic.py under review here is for 3.5. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24000 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24000] More fixes for the Clinic mapping of converters to format units
Larry Hastings added the comment: The length attribute is an internal implementation detail, so its name is not relevant. It's used in the generation of the accompanying length parameter for the impl function for this converter. length is a good name for it. zeroes is not a good name for it. zeroes is, however, a decent name for the converter parameter. I have no quarrel with the documentation using the term NUL. But I don't think the term translates well to use parameter names. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24000 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24000] More fixes for the Clinic mapping of converters to format units
Larry Hastings added the comment: As for why not length instead of zeroes: Because the primary reason for the parameter is specifying that the string can contain embedded zeroes. Returning the length is a side-effect of this, not the main point. If the string didn't have embedded zeroes, we wouldn't need the length. The only reason the code didn't have zeroes=True everywhere was because I screwed up and didn't realize all those mappings *should* have specified it. The documentation is very consistent about calling it a NUL. I don't think NUL=True or allow_NUL=true is particularly attractive; we never (almost never?) use capital letters in parameter names. So any other name is going to be a compromise. allow_null and allow_nul are misspellings, and don't convey the idea any better; they can confuse the reader with the related concept of NULL or None. At least zeroes has the benefit of being an actual word, representing a related concept. Will you be done bikeshedding soon? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24000 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24000] More fixes for the Clinic mapping of converters to format units
Serhiy Storchaka added the comment: In Python 2 and earlier in Python 3 there were no restrictions that arguments for format units s, y, u, z and Z (matching Argument Clinic converters with length=False) shouldn't contain NUL. And this was considered as a bug. As for NUL, ask Victor. It argued for naming it null character/byte and it was consistently changed almost everywhere (left some documentation, but this will be fixed soon). larry.one.more.clinic.format.unit.map.cleanup.5.txt looks almost good to me, but I hesitate about the zeroes parameter. str_converter has the zeroes parameter, but the length attribute. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24000 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24000] More fixes for the Clinic mapping of converters to format units
Serhiy Storchaka added the comment: Doesn't always zeroes == length? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24000 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24000] More fixes for the Clinic mapping of converters to format units
Serhiy Storchaka added the comment: Converters with encoding=True are not used in converted code. es is never used in still non-converted code and et is used only 6 times (for idna and utf-8 encodings) and can be replaced with custom converter or inlined code. So I think the support of encoding=True should be removed from Argument Clinic soon. Converters with length=True are used very rarely too, and they are mostly legacy converters. I think we should get rid of most of them in future. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24000 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24000] More fixes for the Clinic mapping of converters to format units
Larry Hastings added the comment: Oh, heavens, yes, that's much nicer. Thanks for the suggestion, Serhiy! -- Added file: http://bugs.python.org/file39115/larry.one.more.clinic.format.unit.map.cleanup.2.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24000 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24000] More fixes for the Clinic mapping of converters to format units
Serhiy Storchaka added the comment: Doesn't always zeroes == length? zeroes requires length, but length does not require zeroes. As it happens all the format units supported by str always have both parameters either True or False. But the Py_UNICODE converter accepts length for format units u# and Z#, and doesn't support zeroes. length=True implies zeroes=True in the Py_UNICODE converter. u and Z don't allow null characters, u# and Z# allow null characters. zeroes doesn't add any information and isn't needed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24000 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24000] More fixes for the Clinic mapping of converters to format units
Larry Hastings added the comment: u# and Z# allow null characters. Not according to the documentation. 'u' explicitly says it does not allow NUL characters. 'Z', 'u#', and 'Z#' all say they are variants of 'u' but never mention that they might allow NUL characters. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24000 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24000] More fixes for the Clinic mapping of converters to format units
Serhiy Storchaka added the comment: Not according to the documentation. 'u' explicitly says it does not allow NUL characters. 'Z', 'u#', and 'Z#' all say they are variants of 'u' but never mention that they might allow NUL characters. I understand the note in u description as explicitly saying that u# allows null characters. The documentation for format units needs an update for other reasons and there is an issue with ready patch for this. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24000 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24000] More fixes for the Clinic mapping of converters to format units
Larry Hastings added the comment: Doesn't always zeroes == length? zeroes requires length, but length does not require zeroes. As it happens all the format units supported by str always have both parameters either True or False. But the Py_UNICODE converter accepts length for format units u# and Z#, and doesn't support zeroes. I want the converters to accept common parameters. That will make comprehension easier for the casual reader. So I want to keep length as a separate parameter, even for str. So I think the support of encoding=True should be removed from Argument Clinic soon. [...] I think we should get rid of [length] in future. I disagree. My goal with Argument Clinic is that third-party developers will use it to write extensions. And we don't know how many extension modules are using es, es#, et, et#, s#, y#, z#, u#, and U#. I don't think we can remove any of this functionality until 4.0. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24000 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24000] More fixes for the Clinic mapping of converters to format units
Serhiy Storchaka added the comment: I disagree. My goal with Argument Clinic is that third-party developers will use it to write extensions. And we don't know how many extension modules are using es, es#, et, et#, s#, y#, z#, u#, and U#. I don't think we can remove any of this functionality until 4.0. But we can deprecate them sooner. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24000 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24000] More fixes for the Clinic mapping of converters to format units
Larry Hastings added the comment: New diff based on Serhiy's latest round of comments. Thanks, Serhiy! You are inexhaustable! -- Added file: http://bugs.python.org/file39125/larry.one.more.clinic.format.unit.map.cleanup.3.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24000 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24000] More fixes for the Clinic mapping of converters to format units
New submission from Larry Hastings: I found another bug in the mapping of converters to format units. (s#, z#, and y# all allow zeroes.) I've redone the approach for str_converter in an attempt to make it easier to read. It'd be swell if, after this gets checked in (or rejected), somebody *else* took a pass to see if they could find any bugs. -- assignee: larry files: larry.one.more.clinic.format.unit.map.cleanup.1.txt messages: 241468 nosy: larry, serhiy.storchaka, zach.ware priority: normal severity: normal stage: patch review status: open title: More fixes for the Clinic mapping of converters to format units type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file39113/larry.one.more.clinic.format.unit.map.cleanup.1.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24000 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
