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

[Georg Brandl]

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 PyUnicode_strcat are missing documentation.
> 
> It's Py_UNICODE_strcat(), not PyUnicode_strcat(). But yes, Py_UNICODE_strcat() 
> is not documented. But I didn't found any doc for other Py_UNICODE_str*() 
> 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 PyUnicode_strdup() 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.
> 
> PyUnicode_strdup(): I don't like this name. In my first patch, it was called 
> Py_UNICODE_strdup() but all Py_UNICODE_*() functions take Py_UNICODE* 
> 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 "import_unicode" svn branch) at once, so I'm splitting it into atomic 
> commits. PyUnicode_strdup() and Py_UNICODE_strcat() are not used yet, but I 
> plan to use them for the import machinery (Python/import.c) to replace char* 
> by Py_UNICODE*.
> 
>> > 2. Are you sure they need to be public APIs?
> 
> About Py_UNICODE_strcat(): yes, why not? Other Py_UNICODE_str*() functions are 
> pratical but also required to manipulate Py_UNICODE* 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 PyUnicode_strdup() (PyUnicode_AsUnicodeCopy): 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 PyMem_xxx API, I don't know if a third part library would like 
> to rely on PyMem_xxx.

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.