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

M.-A. Lemburg mal at egenix.com
Fri Sep 3 10:01:12 CEST 2010

Victor Stinner wrote:

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. If PyUnicodestrdup() is kept public, it should be documented, yes.

As for naming, I think Py_UNICODE_strdup() is fine, since these functions work directly on Py_UNICODE buffers and they mimic the C functions.

They should be documented, though, even if the documentation is terse and refers to the C API of a similar name.

--

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.

See above: the current naming is fine.

I'd suggest PyUnicodeAsUnicodeCopy() which then corresponds to PyUnicodeFromUnicode(), but I'm not sure whether we should have such a public API in the first place. PyUnicodeAsUnicodeCopy() is maybe a better name, I like it.

For APIs that work on PyUnicodeObjects, we should stick to the naming convention used by the Unicode and string/bytes API. It's a little more verbose, but also provides more clarity than the C API function names.

--

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

This will have to be documented (see PEP 384 for some reasoning on malloc() use in DLLs).

Other than that, ok, let's have them. They do provide some use to other tools working on Py_UNICODE, just like the macros we have for these.

-- Marc-Andre Lemburg eGenix.com

Professional Python Services directly from the Source (#1, Sep 03 2010)

Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

2010-08-19: Released mxODBC 3.1.0 http://python.egenix.com/ 2010-09-15: DZUG Tagung, Dresden, Germany 11 days to go

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/

More information about the Python-Dev mailing list