[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 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python

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

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

[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: ``es``

[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

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

[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

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.

[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

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