This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author larry
Recipients benjamin.peterson, georg.brandl, larry, lemburg
Date 2015-04-17.03:50:40
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1429242641.5.0.823130320938.issue23980@psf.upfronthosting.co.za>
In-reply-to
Content
> 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 guess the "e" descriptions need to have the additional * removed
> or the paragraph has to be updated and all other listings need
> to be converted to precise types (that would be my preference).

Here's the problem with removing the "additional *".  The first argument
to encoding is a static string.  You literally pass in the char * string,
not a pointer to a variable containing the address of the string.  e.g.

  PyArg_ParseTuple("es", args, "utf-8", &buffer);

So how do we annotate that?  [char, char *]?

> I wonder why no one has noticed in all these years.

Because nobody ever freaking uses the "e" format units.  But by golly
I'm going to see that the docs are right and Clinic supports them
correctly--or die trying.
History
Date User Action Args
2015-04-17 03:50:41larrysetrecipients: + larry, lemburg, georg.brandl, benjamin.peterson
2015-04-17 03:50:41larrysetmessageid: <1429242641.5.0.823130320938.issue23980@psf.upfronthosting.co.za>
2015-04-17 03:50:41larrylinkissue23980 messages
2015-04-17 03:50:41larrycreate