Staging
v0.5.1
https://github.com/python/cpython
Revision 935f09aea1ab7eb60e881b88d3f82e2ac92bcf98 authored by Florent Xicluna on 09 August 2010, 22:15:51 UTC, committed by Florent Xicluna on 09 August 2010, 22:15:51 UTC
................
  r83902 | florent.xicluna | 2010-08-09 22:02:00 +0200 (lun., 09 août 2010) | 25 lines

  Merged revisions 83833,83838-83839,83859,83878 via svnmerge from
  svn+ssh://pythondev@svn.python.org/python/branches/py3k

  ........
    r83833 | florent.xicluna | 2010-08-08 18:25:27 +0200 (dim., 08 août 2010) | 2 lines

    Add test case for the HTTPResponse being an iterable.  Follow-up of issue #4608.
  ........
    r83838 | florent.xicluna | 2010-08-08 20:03:44 +0200 (dim., 08 août 2010) | 2 lines

    Typo.
  ........
    r83839 | florent.xicluna | 2010-08-08 20:06:13 +0200 (dim., 08 août 2010) | 2 lines

    Issue #7564: Skip test_ioctl if another process is attached to /dev/tty.
  ........
    r83859 | florent.xicluna | 2010-08-09 00:07:16 +0200 (lun., 09 août 2010) | 2 lines

    Fix #8530: Prevent stringlib fastsearch from reading beyond the front of an array.
  ........
    r83878 | florent.xicluna | 2010-08-09 10:29:08 +0200 (lun., 09 août 2010) | 1 line

    Merge the 2to3 script from /sandbox/trunk/2to3/2to3, revision 72867 (latest).
  ........
................
  r83907 | florent.xicluna | 2010-08-09 22:29:44 +0200 (lun., 09 août 2010) | 27 lines

  Missed the svnmerge property on r83902.

  Recorded merge of revisions 83833,83838-83839,83859,83878 via svnmerge from
  svn+ssh://pythondev@svn.python.org/python/branches/py3k

  ........
    r83833 | florent.xicluna | 2010-08-08 18:25:27 +0200 (dim., 08 août 2010) | 2 lines

    Add test case for the HTTPResponse being an iterable.  Follow-up of issue #4608.
  ........
    r83838 | florent.xicluna | 2010-08-08 20:03:44 +0200 (dim., 08 août 2010) | 2 lines

    Typo.
  ........
    r83839 | florent.xicluna | 2010-08-08 20:06:13 +0200 (dim., 08 août 2010) | 2 lines

    Issue #7564: Skip test_ioctl if another process is attached to /dev/tty.
  ........
    r83859 | florent.xicluna | 2010-08-09 00:07:16 +0200 (lun., 09 août 2010) | 2 lines

    Fix #8530: Prevent stringlib fastsearch from reading beyond the front of an array.
  ........
    r83878 | florent.xicluna | 2010-08-09 10:29:08 +0200 (lun., 09 août 2010) | 1 line

    Merge the 2to3 script from /sandbox/trunk/2to3/2to3, revision 72867 (latest).
  ........
................
1 parent ca2a48f
Raw File
Tip revision: 935f09aea1ab7eb60e881b88d3f82e2ac92bcf98 authored by Florent Xicluna on 09 August 2010, 22:15:51 UTC
Blocked revisions 83902,83907 via svnmerge
Tip revision: 935f09a
pymemcompat.h
/* The idea of this file is that you bundle it with your extension,
   #include it, program to Python 2.3's memory API and have your
   extension build with any version of Python from 1.5.2 through to
   2.3 (and hopefully beyond). */

#ifndef Py_PYMEMCOMPAT_H
#define Py_PYMEMCOMPAT_H

#include "Python.h"

/* There are three "families" of memory API: the "raw memory", "object
   memory" and "object" families.  (This is ignoring the matter of the
   cycle collector, about which more is said below).

   Raw Memory:

       PyMem_Malloc, PyMem_Realloc, PyMem_Free

   Object Memory:

       PyObject_Malloc, PyObject_Realloc, PyObject_Free

   Object:

       PyObject_New, PyObject_NewVar, PyObject_Del

   The raw memory and object memory allocators both mimic the
   malloc/realloc/free interface from ANSI C, but the object memory
   allocator can (and, since 2.3, does by default) use a different
   allocation strategy biased towards lots of "small" allocations.

   The object family is used for allocating Python objects, and the
   initializers take care of some basic initialization (setting the
   refcount to 1 and filling out the ob_type field) as well as having
   a somewhat different interface.

   Do not mix the families!  E.g. do not allocate memory with
   PyMem_Malloc and free it with PyObject_Free.  You may get away with
   it quite a lot of the time, but there *are* scenarios where this
   will break.  You Have Been Warned. 

   Also, in many versions of Python there are an insane amount of
   memory interfaces to choose from.  Use the ones described above. */

#if PY_VERSION_HEX < 0x01060000
/* raw memory interface already present */

/* there is no object memory interface in 1.5.2 */
#define PyObject_Malloc		PyMem_Malloc
#define PyObject_Realloc	PyMem_Realloc
#define PyObject_Free		PyMem_Free

/* the object interface is there, but the names have changed */
#define PyObject_New		PyObject_NEW
#define PyObject_NewVar		PyObject_NEW_VAR
#define PyObject_Del		PyMem_Free
#endif

/* If your object is a container you probably want to support the
   cycle collector, which was new in Python 2.0.

   Unfortunately, the interface to the collector that was present in
   Python 2.0 and 2.1 proved to be tricky to use, and so changed in
   2.2 -- in a way that can't easily be papered over with macros.

   This file contains macros that let you program to the 2.2 GC API.
   Your module will compile against any Python since version 1.5.2,
   but the type will only participate in the GC in versions 2.2 and
   up.  Some work is still necessary on your part to only fill out the
   tp_traverse and tp_clear fields when they exist and set tp_flags
   appropriately.

   It is possible to support both the 2.0 and 2.2 GC APIs, but it's
   not pretty and this comment block is too narrow to contain a
   desciption of what's required... */

#if PY_VERSION_HEX < 0x020200B1
#define PyObject_GC_New         PyObject_New
#define PyObject_GC_NewVar      PyObject_NewVar
#define PyObject_GC_Del         PyObject_Del
#define PyObject_GC_Track(op)
#define PyObject_GC_UnTrack(op)
#endif

#endif /* !Py_PYMEMCOMPAT_H */
back to top