diff --git a/MANIFEST.in b/MANIFEST.in
index 54b1fd5..4e03cc4 100644
--- a/MANIFEST.in
+++ b/MANIFEST.in
@@ -6,7 +6,6 @@ include HISTORY
 include INSTALL
 include README.md
 include GPL-2.0
-include pymemcompat.h
 include metadata.cfg
 include site.cfg
 include setup_common.py
diff --git a/_mysql.c b/_mysql.c
index 8b815fb..1664913 100644
--- a/_mysql.c
+++ b/_mysql.c
@@ -36,7 +36,6 @@ PERFORMANCE OF THIS SOFTWARE.
 #endif
 
 #include "bytesobject.h"
-#include "pymemcompat.h"
 #include "structmember.h"
 #if defined(MS_WINDOWS)
 #include <config-win.h>
diff --git a/pymemcompat.h b/pymemcompat.h
deleted file mode 100644
index e7c538c..0000000
--- a/pymemcompat.h
+++ /dev/null
@@ -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 */