Mercurial > p > mysql-python > mysqldb-2
changeset 28:5a3e4cafadec MySQLdb
Clean out the old 1.x and 2.2 era memory workarounds (our minimum is 2.3).
Partial application of SF patch 2506449.
author | kylev |
---|---|
date | Sat, 07 Feb 2009 22:48:05 +0000 |
parents | d301c95d8fd7 |
children | fbf2470ea3d4 |
files | MANIFEST.in _mysql.h pymemcompat.h |
diffstat | 3 files changed, 11 insertions(+), 107 deletions(-) [+] |
line wrap: on
line diff
--- a/MANIFEST.in Sat Feb 07 21:13:51 2009 +0000 +++ b/MANIFEST.in Sat Feb 07 22:48:05 2009 +0000 @@ -4,7 +4,6 @@ include ChangeLog include HISTORY include GPL -include pymemcompat.h recursive-include tests *.py include metadata.cfg include site.cfg
--- a/_mysql.h Sat Feb 07 21:13:51 2009 +0000 +++ b/_mysql.h Sat Feb 07 22:48:05 2009 +0000 @@ -1,7 +1,7 @@ #ifndef _MYSQL_PYTHON__MYSQL_H_ #define _MYSQL_PYTHON__MYSQL_H_ -#include "pymemcompat.h" +#include <Python.h> #ifdef MS_WIN32 #include <windows.h> @@ -13,19 +13,11 @@ #include "mysqld_error.h" #include "errmsg.h" -#if PY_VERSION_HEX < 0x02020000 -# define MyTuple_Resize(t,n,d) _PyTuple_Resize(t, n, d) -# define MyMember(a,b,c,d,e) {a,b,c,d} -# define MyMemberlist(x) struct memberlist x -# define MyAlloc(s,t) PyObject_New(s,&t) -# define MyFree(o) PyObject_Del(o) -#else -# define MyTuple_Resize(t,n,d) _PyTuple_Resize(t, n) -# define MyMember(a,b,c,d,e) {a,b,c,d,e} -# define MyMemberlist(x) struct PyMemberDef x -# define MyAlloc(s,t) (s *) t.tp_alloc(&t,0) -# define MyFree(ob) ob->ob_type->tp_free((PyObject *)ob) -#endif +#define MyTuple_Resize(t,n,d) _PyTuple_Resize(t, n) +#define MyMember(a,b,c,d,e) {a,b,c,d,e} +#define MyMemberlist(x) struct PyMemberDef x +#define MyAlloc(s,t) (s *) t.tp_alloc(&t,0) +#define MyFree(ob) ob->ob_type->tp_free((PyObject *)ob) #if PY_VERSION_HEX < 0x02050000 && !defined(PY_SSIZE_T_MIN) typedef int Py_ssize_t; @@ -77,11 +69,11 @@ extern PyObject *_mysql_Warning; extern PyObject *_mysql_Error; extern PyObject *_mysql_DatabaseError; -extern PyObject *_mysql_InterfaceError; +extern PyObject *_mysql_InterfaceError; extern PyObject *_mysql_DataError; -extern PyObject *_mysql_OperationalError; -extern PyObject *_mysql_IntegrityError; -extern PyObject *_mysql_InternalError; +extern PyObject *_mysql_OperationalError; +extern PyObject *_mysql_IntegrityError; +extern PyObject *_mysql_InternalError; extern PyObject *_mysql_ProgrammingError; extern PyObject *_mysql_NotSupportedError; extern PyObject *_mysql_error_map; @@ -100,5 +92,5 @@ _mysql_FieldObject *self, PyObject *args, PyObject *kwargs); - + #endif
--- a/pymemcompat.h Sat Feb 07 21:13:51 2009 +0000 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,87 +0,0 @@ - -/* 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 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 */