Re: [Python-Dev] r84430 - in python/branches/py3k: Include/unicodeobject.h Objects/unicodeobject.c
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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r84430 - in python/branches/py3k: Include/unicodeobject.h Objects/unicodeobject.c
Victor Stinner wrote: 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. If PyUnicode_strdup() 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. 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. See above: the current naming is fine. I'd suggest PyUnicode_AsUnicodeCopy() which then corresponds to PyUnicode_FromUnicode(), but I'm not sure whether we should have such a public API in the first place. PyUnicode_AsUnicodeCopy() 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 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. 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. 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/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r84430 - in python/branches/py3k: Include/unicodeobject.h Objects/unicodeobject.c
On Thu, Sep 2, 2010 at 6:26 PM, Victor Stinner victor.stin...@haypocalc.com wrote: But I didn't found any doc for other Py_UNICODE_str*() functions in Doc/c-api/*.rst. http://bugs.python.org/issue8649 - Py_UNICODE_* functions are undocumented -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises, LLC http://stutzbachenterprises.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r84430 - in python/branches/py3k: Include/unicodeobject.h Objects/unicodeobject.c
Le vendredi 03 septembre 2010 11:20:04, vous avez écrit : But I didn't found any doc for other Py_UNICODE_str*() functions in Doc/c-api/*.rst. http://bugs.python.org/issue8649 - Py_UNICODE_* functions are undocumented Opened since 3 months. It looks like programmers don't like writing documentation :-) -- Victor Stinner http://www.haypocalc.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r84430 - in python/branches/py3k: Include/unicodeobject.h Objects/unicodeobject.c
On Fri, Sep 3, 2010 at 8:14 PM, Victor Stinner victor.stin...@haypocalc.com wrote: Le vendredi 03 septembre 2010 11:20:04, vous avez écrit : But I didn't found any doc for other Py_UNICODE_str*() functions in Doc/c-api/*.rst. http://bugs.python.org/issue8649 - Py_UNICODE_* functions are undocumented Opened since 3 months. It looks like programmers don't like writing documentation :-) In this case, C programmers think C stdlib function names are intuitive may be closer to the mark ;) Cheers, Nick. P.S. More seriously, these particular functions really are just like the standard C function of the same name, only operating on Py_UNICODE* rather than char*, so I can understand documentation being skipped when they were added. However, they may as well be mentioned in http://docs.python.org/dev/c-api/unicode.html#plain-py-unicode -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r84430 - in python/branches/py3k: Include/unicodeobject.h Objects/unicodeobject.c
On Fri, Sep 3, 2010 at 6:01 PM, M.-A. Lemburg m...@egenix.com wrote: 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. This will have to be documented (see PEP 384 for some reasoning on malloc() use in DLLs). PyUnicode_AsUnicodeCopy is indeed a better name. As far as the need to call PyMem_Free goes, a similar requirement already exists for argument parsing via es and es# (see http://docs.python.org/dev/c-api/arg.html#strings-and-buffers), so just documenting it is fine. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r84430 - in python/branches/py3k: Include/unicodeobject.h Objects/unicodeobject.c
Le vendredi 03 septembre 2010 10:01:12, vous avez écrit : (...) 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. This will have to be documented (see PEP 384 for some reasoning on malloc() use in DLLs). It is already documented in unicodeobject.h. Other than that, ok, let's have them. Ok. r84455 renames PyUnicode_strdup() to PyUnicode_AsUnicodeCopy(), and r84456 document it: -- .. cfunction:: Py_UNICODE* PyUnicode_AsUnicodeCopy(PyObject *unicode) Create a copy of a unicode string ending with a nul character. Return *NULL* and raise a :exc:`MemoryError` exception on memory allocation failure, otherwise return a new allocated buffer (use :cfunc:`PyMem_Free` to free the buffer). -- Thanks all for your review and advices ;-) -- Victor Stinner http://www.haypocalc.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r84430 - in python/branches/py3k: Include/unicodeobject.h Objects/unicodeobject.c
Am 03.09.2010 18:24, schrieb Victor Stinner: Other than that, ok, let's have them. Ok. r84455 renames PyUnicode_strdup() to PyUnicode_AsUnicodeCopy(), and r84456 document it: -- ... cfunction:: Py_UNICODE* PyUnicode_AsUnicodeCopy(PyObject *unicode) Create a copy of a unicode string ending with a nul character. Return *NULL* and raise a :exc:`MemoryError` exception on memory allocation failure, otherwise return a new allocated buffer (use :cfunc:`PyMem_Free` to free the buffer). -- Thanks all for your review and advices ;-) What about Py_UNICODE_strcat? If it remains, it needs to be documented as well. 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r84430 - in python/branches/py3k: Include/unicodeobject.h Objects/unicodeobject.c
Le samedi 04 septembre 2010 00:02:59, Georg Brandl a écrit : What about Py_UNICODE_strcat? If it remains, it needs to be documented as well. There is already an issue for that: http://bugs.python.org/issue8649 -- Victor Stinner http://www.haypocalc.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r84430 - in python/branches/py3k: Include/unicodeobject.h Objects/unicodeobject.c
Hi Victor,
1. This function and PyUnicode_strcat are missing documentation.
2. Are you sure they need to be public APIs? What are they going to
be used for? (I'm not sure myself, but I think we usually have a
short notice here when new C APIs are added.)
Georg
Am 02.09.2010 01:43, schrieb victor.stinner:
Author: victor.stinner
Date: Thu Sep 2 01:43:53 2010
New Revision: 84430
Log:
Create PyUnicode_strdup() function
Modified:
python/branches/py3k/Include/unicodeobject.h
python/branches/py3k/Objects/unicodeobject.c
Modified: python/branches/py3k/Include/unicodeobject.h
==
--- python/branches/py3k/Include/unicodeobject.h (original)
+++ python/branches/py3k/Include/unicodeobject.h Thu Sep 2 01:43:53 2010
@@ -220,6 +220,7 @@
# define _PyUnicode_AsDefaultEncodedString
_PyUnicodeUCS2_AsDefaultEncodedString
# define _PyUnicode_Fini _PyUnicodeUCS2_Fini
# define _PyUnicode_Init _PyUnicodeUCS2_Init
+# define PyUnicode_strdup PyUnicodeUCS2_strdup
#else
@@ -302,7 +303,7 @@
# define _PyUnicode_AsDefaultEncodedString
_PyUnicodeUCS4_AsDefaultEncodedString
# define _PyUnicode_Fini _PyUnicodeUCS4_Fini
# define _PyUnicode_Init _PyUnicodeUCS4_Init
-
+# define PyUnicode_strdup PyUnicodeUCS4_strdup
#endif
@@ -1602,6 +1603,14 @@
Py_UNICODE c
);
+/* Create a copy of a unicode string ending with a nul character. Return NULL
+ and raise a MemoryError exception on memory allocation failure, otherwise
+ return a new allocated buffer (use PyMem_Free() to free the buffer). */
+
+PyAPI_FUNC(Py_UNICODE*) PyUnicode_strdup(
+PyObject *unicode
+);
+
#ifdef __cplusplus
}
#endif
Modified: python/branches/py3k/Objects/unicodeobject.c
==
--- python/branches/py3k/Objects/unicodeobject.c (original)
+++ python/branches/py3k/Objects/unicodeobject.c Thu Sep 2 01:43:53 2010
@@ -10014,6 +10014,28 @@
return NULL;
}
+Py_UNICODE*
+PyUnicode_strdup(PyObject *object)
+{
+PyUnicodeObject *unicode = (PyUnicodeObject *)object;
+Py_UNICODE *copy;
+Py_ssize_t size;
+
+/* Ensure we won't overflow the size. */
+if (PyUnicode_GET_SIZE(unicode) ((PY_SSIZE_T_MAX / sizeof(Py_UNICODE))
- 1)) {
+PyErr_NoMemory();
+return NULL;
+}
+size = PyUnicode_GET_SIZE(unicode) + 1; /* copy the nul character */
+size *= sizeof(Py_UNICODE);
+copy = PyMem_Malloc(size);
+if (copy == NULL) {
+PyErr_NoMemory();
+return NULL;
+}
+memcpy(copy, PyUnicode_AS_UNICODE(unicode), size);
+return copy;
+}
#ifdef __cplusplus
}
--
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.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r84430 - in python/branches/py3k: Include/unicodeobject.h Objects/unicodeobject.c
Georg Brandl wrote:
Hi Victor,
1. This function and PyUnicode_strcat are missing documentation.
2. Are you sure they need to be public APIs? What are they going to
be used for? (I'm not sure myself, but I think we usually have a
short notice here when new C APIs are added.)
If you want to make this a public API function, it also needs to be
renamed to fit the rest of the API.
I'd suggest PyUnicode_AsUnicodeCopy() which then corresponds
to PyUnicode_FromUnicode(), but I'm not sure whether we should
have such a public API in the first place.
Georg
Am 02.09.2010 01:43, schrieb victor.stinner:
Author: victor.stinner
Date: Thu Sep 2 01:43:53 2010
New Revision: 84430
Log:
Create PyUnicode_strdup() function
Modified:
python/branches/py3k/Include/unicodeobject.h
python/branches/py3k/Objects/unicodeobject.c
Modified: python/branches/py3k/Include/unicodeobject.h
==
--- python/branches/py3k/Include/unicodeobject.h (original)
+++ python/branches/py3k/Include/unicodeobject.h Thu Sep 2 01:43:53 2010
@@ -220,6 +220,7 @@
# define _PyUnicode_AsDefaultEncodedString
_PyUnicodeUCS2_AsDefaultEncodedString
# define _PyUnicode_Fini _PyUnicodeUCS2_Fini
# define _PyUnicode_Init _PyUnicodeUCS2_Init
+# define PyUnicode_strdup PyUnicodeUCS2_strdup
#else
@@ -302,7 +303,7 @@
# define _PyUnicode_AsDefaultEncodedString
_PyUnicodeUCS4_AsDefaultEncodedString
# define _PyUnicode_Fini _PyUnicodeUCS4_Fini
# define _PyUnicode_Init _PyUnicodeUCS4_Init
-
+# define PyUnicode_strdup PyUnicodeUCS4_strdup
#endif
@@ -1602,6 +1603,14 @@
Py_UNICODE c
);
+/* Create a copy of a unicode string ending with a nul character. Return
NULL
+ and raise a MemoryError exception on memory allocation failure, otherwise
+ return a new allocated buffer (use PyMem_Free() to free the buffer). */
+
+PyAPI_FUNC(Py_UNICODE*) PyUnicode_strdup(
+PyObject *unicode
+);
+
#ifdef __cplusplus
}
#endif
Modified: python/branches/py3k/Objects/unicodeobject.c
==
--- python/branches/py3k/Objects/unicodeobject.c (original)
+++ python/branches/py3k/Objects/unicodeobject.c Thu Sep 2 01:43:53 2010
@@ -10014,6 +10014,28 @@
return NULL;
}
+Py_UNICODE*
+PyUnicode_strdup(PyObject *object)
+{
+PyUnicodeObject *unicode = (PyUnicodeObject *)object;
+Py_UNICODE *copy;
+Py_ssize_t size;
+
+/* Ensure we won't overflow the size. */
+if (PyUnicode_GET_SIZE(unicode) ((PY_SSIZE_T_MAX /
sizeof(Py_UNICODE)) - 1)) {
+PyErr_NoMemory();
+return NULL;
+}
+size = PyUnicode_GET_SIZE(unicode) + 1; /* copy the nul character */
+size *= sizeof(Py_UNICODE);
+copy = PyMem_Malloc(size);
+if (copy == NULL) {
+PyErr_NoMemory();
+return NULL;
+}
+memcpy(copy, PyUnicode_AS_UNICODE(unicode), size);
+return copy;
+}
#ifdef __cplusplus
}
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Sep 02 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 12 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/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r84430 - in python/branches/py3k: Include/unicodeobject.h Objects/unicodeobject.c
On Thu, Sep 2, 2010 at 6:51 PM, Georg Brandl g.bra...@gmx.net wrote: Hi Victor, 1. This function and PyUnicode_strcat are missing documentation. 2. Are you sure they need to be public APIs? What are they going to be used for? (I'm not sure myself, but I think we usually have a short notice here when new C APIs are added.) I believe I first saw them on Victor's branch for improved Unicode support (especially in the context of import). I agree that private _Py prefixes are probably a better idea here. The public API should focus on Py_Unicode, with only a minimal collection of Py_UNICODE interfaces. Regarding the naming scheme, if these are what I recall them as (drop in replacements for the 8-bit C stdlib equivalents to simplify the relevant import.c updates), I'm fine with the current naming for private API functions, but agree with MAL they should be made more explicit if they're part of the published API. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r84430 - in python/branches/py3k: Include/unicodeobject.h Objects/unicodeobject.c
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. 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'd suggest PyUnicode_AsUnicodeCopy() which then corresponds to PyUnicode_FromUnicode(), but I'm not sure whether we should have such a public API in the first place. PyUnicode_AsUnicodeCopy() is maybe a better name, I like it. -- 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. 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. -- Victor Stinner http://www.haypocalc.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r84430 - in python/branches/py3k: Include/unicodeobject.h Objects/unicodeobject.c
Le jeudi 02 septembre 2010 23:19:04, Nick Coghlan a écrit : On Thu, Sep 2, 2010 at 6:51 PM, Georg Brandl g.bra...@gmx.net wrote: Hi Victor, 1. This function and PyUnicode_strcat are missing documentation. 2. Are you sure they need to be public APIs? What are they going to be used for? (I'm not sure myself, but I think we usually have a short notice here when new C APIs are added.) I believe I first saw them on Victor's branch for improved Unicode support (especially in the context of import). Yes, it is used in my branch. Py_UNICODE_strcat() is used in make_compiled_pathname(). Py_UNICODE_strdup() is used in make_source_pathname() and make_compiled_pathname(). I agree that private _Py prefixes are probably a better idea here. The public API should focus on Py_Unicode, with only a minimal collection of Py_UNICODE interfaces. Are you talking about Py_UNICODE_strcat() or Py_UNICODE_strdup() (called PyUnicode_strdup in py3k branch)? -- Victor Stinner http://www.haypocalc.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
