[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 __

[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

[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 ___ ___

[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

[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

[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, w

[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 ___ ___ Python-bugs-list mailing list Un

[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 ___

[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

[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 ___ __

[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

[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 "Py

[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 Pytho

[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'r

[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 expli

[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 <

[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. -- _

[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 functi

[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

[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 for

[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

[issue24000] More fixes for the Clinic mapping of converters to format units

Serhiy Storchaka added the comment: Doesn't always zeroes == length? -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsub

[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

[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 *e