A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2010-September/103425.html below:

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

[Python-Dev] r84430 - in python/branches/py3k: Include/unicodeobject.h Objects/unicodeobject.c [Python-Dev] r84430 - in python/branches/py3k: Include/unicodeobject.h Objects/unicodeobject.cNick Coghlan ncoghlan at gmail.com
Fri Sep 3 13:02:50 CEST 2010
On Fri, Sep 3, 2010 at 6:01 PM, M.-A. Lemburg <mal at 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   |   ncoghlan at gmail.com   |   Brisbane, Australia
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4