[issue23980] Documentation for format units starting with 'e' is inconsistent

Change by Zackery Spytz : -- versions: +Python 3.7, Python 3.8, Python 3.9 -Python 2.7, Python 3.4, Python 3.5 ___ Python tracker ___

[issue23980] Documentation for format units starting with 'e' is inconsistent

Change by Zackery Spytz : -- keywords: +patch nosy: +ZackerySpytz nosy_count: 7.0 -> 8.0 pull_requests: +18944 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/19610 ___ Python tracker

[issue23980] Documentation for format units starting with 'e' is inconsistent

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker ___ ___

[issue23980] Documentation for format units starting with 'e' is inconsistent

Serhiy Storchaka added the comment: LGTM. -- nosy: +serhiy.storchaka ___ Python tracker ___ ___

[issue23980] Documentation for format units starting with 'e' is inconsistent

Martin Panter added the comment: The O! and O& units are in a similar situation. They just use a different font and descriptive name, rather than a specific type: ``O!`` (object) [*typeobject*, PyObject \*] ``O&`` (object) [*converter*, *anything*] Following this lead, you could write:

[issue23980] Documentation for format units starting with 'e' is inconsistent

Marc-Andre Lemburg added the comment: On 17.04.2015 05:50, Larry Hastings wrote: Larry Hastings added the comment: The e variants (typically) allocate a buffer for you, since it's pretty much unknown how long the encoded data will be. All four will do it if you pass in a NULL pointer.

[issue23980] Documentation for format units starting with 'e' is inconsistent

Marc-Andre Lemburg added the comment: On 17.04.2015 06:42, Larry Hastings wrote: Larry Hastings added the comment: One more idea. We annotate with an when you pass in a pointer to a variable. So format unit 'i' would get [ int], 's' would get [ char *], and 'es#' would get [char *,

[issue23980] Documentation for format units starting with 'e' is inconsistent

Larry Hastings added the comment: One more idea. We annotate with an when you pass in a pointer to a variable. So format unit 'i' would get [ int], 's' would get [ char *], and 'es#' would get [char *, char *, int]. -- ___ Python tracker

[issue23980] Documentation for format units starting with 'e' is inconsistent

Marc-Andre Lemburg added the comment: On 17.04.2015 01:38, Larry Hastings wrote: Documentation is here: https://docs.python.org/3/c-api/arg.html#arg-parsing The first line of documentation for each format unit follows this convention: formatunit (pythontype) [arguments, to,

[issue23980] Documentation for format units starting with 'e' is inconsistent

New submission from Larry Hastings: Documentation is here: https://docs.python.org/3/c-api/arg.html#arg-parsing The first line of documentation for each format unit follows this convention: formatunit (pythontype) [arguments, to, pyarg_parsetuple] These represent the format unit

[issue23980] Documentation for format units starting with 'e' is inconsistent

Larry Hastings added the comment: The e variants (typically) allocate a buffer for you, since it's pretty much unknown how long the encoded data will be. All four will do it if you pass in a NULL pointer. es# and et# can reuse an existing buffer, because you can also pass in its size. So I