[Python-Dev] r84430 - in python/branches/py3k: Include/unicodeobject.h Objects/unicodeobject.c (original) (raw)

Georg Brandl g.brandl at gmx.net
Fri Sep 3 09:32:10 CEST 2010

Am 03.09.2010 01:26, schrieb Victor Stinner:

Hi,

Le jeudi 02 septembre 2010 11:13:22, vous avez écrit : > 1. This function and PyUnicodestrcat are missing documentation. It's PyUNICODEstrcat(), not PyUnicodestrcat(). But yes, PyUNICODEstrcat() is not documented. But I didn't found any doc for other PyUNICODEstr*() functions in Doc/c-api/*.rst. Does it mean that we should write a document for all these functions? They mimic the str*() C API.

Yes. All public functions should be documented. I know that some existing functions are not; that should not be a guideline for new functions though.

If PyUnicodestrdup() is kept public, it should be documented, yes.

If you want to make this a public API function, it also needs to be renamed to fit the rest of the API. PyUnicodestrdup(): I don't like this name. In my first patch, it was called PyUNICODEstrdup() but all PyUNICODE*() functions take PyUNICODE* arguments, no PyUnicodeObject* argument.

I'll leave the naming decisions to Marc-Andre.

What are they going to be used for? I am not able to merge my huge work on unicode import (see #8611, #9425 and the "importunicode" svn branch) at once, so I'm splitting it into atomic commits. PyUnicodestrdup() and PyUNICODEstrcat() are not used yet, but I plan to use them for the import machinery (Python/import.c) to replace char* by PyUNICODE*.

> 2. Are you sure they need to be public APIs? About PyUNICODEstrcat(): yes, why not? Other PyUNICODEstr*() functions are pratical but also required to manipulate PyUNICODE* strings.

For public APIs, the question is not "why not", but "why". If they are needed for the import machinery in Unicode, sure they are useful, but that's no reason to make them public. I'd recommend to start out with _Py prefixes, and avoid any new public APIs unless they are asked for.

About PyUnicodestrdup() (PyUnicodeAsUnicodeCopy): I don't know. It is possible to rewrite it in few lines. Why don't you want to add them to the public API? For my work, it doesn't matter if it's public or not. This function uses PyMemxxx API, I don't know if a third part library would like to rely on PyMemxxx.

cheers, Georg

-- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

More information about the Python-Dev mailing list