[Python-3000-checkins] r65862 - in python/branches/py3k: Include/memoryobject.h Misc/NEWS Modules/_json.c Objects/memoryobject.c Objects/unicodeobject.c

[antoine.pitrou]

Author: antoine.pitrou
Date: Tue Aug 19 20:22:14 2008
New Revision: 65862

Log:
#3560: cleanup C memoryview API



Modified:
python/branches/py3k/Include/memoryobject.h
python/branches/py3k/Misc/NEWS
python/branches/py3k/Modules/_json.c
python/branches/py3k/Objects/memoryobject.c
python/branches/py3k/Objects/unicodeobject.c

Modified: python/branches/py3k/Include/memoryobject.h
==============================================================================
--- python/branches/py3k/Include/memoryobject.h (original)
+++ python/branches/py3k/Include/memoryobject.h Tue Aug 19 20:22:14 2008
@@ -1,5 +1,4 @@
-
-/* Memory object interface */
+/* Memory view object. In Python this is available as "memoryview". */

#ifndef Py_MEMORYOBJECT_H
#define Py_MEMORYOBJECT_H
@@ -7,19 +6,15 @@
extern "C" {
#endif

-typedef struct {
- PyObject_HEAD
- PyObject *base;
- Py_buffer view;
-} PyMemoryViewObject;
-
-
PyAPI_DATA(PyTypeObject) PyMemoryView_Type;

-#define PyMemory_Check(op) (Py_TYPE(op) == &PyMemoryView_Type)
-#define PyMemoryView(op) (((PyMemoryViewObject *)(op))->view)
+#define PyMemoryView_Check(op) (Py_TYPE(op) == &PyMemoryView_Type)
+
+/* Get a pointer to the underlying Py_buffer of a memoryview object. */
+#define PyMemoryView_GET_BUFFER(op) (&((PyMemoryViewObject *)(op))->view)
+/* Get a pointer to the PyObject from which originates a memoryview object. */
+#define PyMemoryView_GET_BASE(op) (((PyMemoryViewObject *)(op))->view.obj)

-#define Py_END_OF_MEMORY (-1)

PyAPI_FUNC(PyObject *) PyMemoryView_GetContiguous(PyObject *base,
int buffertype,
@@ -58,10 +53,21 @@

PyAPI_FUNC(PyObject *) PyMemoryView_FromObject(PyObject *base);

-PyAPI_FUNC(PyObject *) PyMemoryView_FromMemory(Py_buffer *info);
+PyAPI_FUNC(PyObject *) PyMemoryView_FromBuffer(Py_buffer *info);
/* create new if bufptr is NULL
will be a new bytesobject in base */

+
+/* The struct is declared here so that macros can work, but it shouldn't
+ be considered public. Don't access those fields directly, use the macros
+ and functions instead! */
+typedef struct {
+ PyObject_HEAD
+ PyObject *base;
+ Py_buffer view;
+} PyMemoryViewObject;
+
+
#ifdef __cplusplus
}
#endif

Modified: python/branches/py3k/Misc/NEWS
==============================================================================
--- python/branches/py3k/Misc/NEWS (original)
+++ python/branches/py3k/Misc/NEWS Tue Aug 19 20:22:14 2008
@@ -12,6 +12,12 @@
Core and Builtins
-----------------

+- Issue #3560: clean up the new C PyMemoryView API so that naming is
+ internally consistent; add macros PyMemoryView_GET_BASE() and
+ PyMemoryView_GET_BUFFER() to access useful properties of a memory views
+ without relying on a particular implementation; remove the ill-named
+ PyMemoryView() function (PyMemoryView_GET_BUFFER() can be used instead).
+
- Issue #1819: function calls with several named parameters are now on
average 35% faster (as measured by pybench).


Modified: python/branches/py3k/Modules/_json.c
==============================================================================
--- python/branches/py3k/Modules/_json.c (original)
+++ python/branches/py3k/Modules/_json.c Tue Aug 19 20:22:14 2008
@@ -264,7 +264,7 @@
if (PyBuffer_FillInfo(&info, NULL, &buf[end], next - end, 1, 0) < 0) {
goto bail;
}
- strchunk = PyMemoryView_FromMemory(&info);
+ strchunk = PyMemoryView_FromBuffer(&info);
if (strchunk == NULL) {
goto bail;
}

Modified: python/branches/py3k/Objects/memoryobject.c
==============================================================================
--- python/branches/py3k/Objects/memoryobject.c (original)
+++ python/branches/py3k/Objects/memoryobject.c Tue Aug 19 20:22:14 2008
@@ -29,7 +29,7 @@
Create a new memoryview object which references the given object.");

PyObject *
-PyMemoryView_FromMemory(Py_buffer *info)
+PyMemoryView_FromBuffer(Py_buffer *info)
{
PyMemoryViewObject *mview;

@@ -231,7 +231,7 @@
mem = PyObject_New(PyMemoryViewObject, &PyMemoryView_Type);
if (mem == NULL) return NULL;

- view = &PyMemoryView(mem);
+ view = &mem->view;
flags = PyBUF_FULL_RO;
switch(buffertype) {
case PyBUF_WRITE:
@@ -534,7 +534,7 @@
/* XXX: This needs to be fixed so it
actually returns a sub-view
*/
- return PyMemoryView_FromMemory(&newview);
+ return PyMemoryView_FromBuffer(&newview);
}
}


Modified: python/branches/py3k/Objects/unicodeobject.c
==============================================================================
--- python/branches/py3k/Objects/unicodeobject.c (original)
+++ python/branches/py3k/Objects/unicodeobject.c Tue Aug 19 20:22:14 2008
@@ -1200,7 +1200,7 @@
buffer = NULL;
if (PyBuffer_FillInfo(&info, NULL, (void *)s, size, 1, PyBUF_SIMPLE) < 0)
goto onError;
- buffer = PyMemoryView_FromMemory(&info);
+ buffer = PyMemoryView_FromBuffer(&info);
if (buffer == NULL)
goto onError;
unicode = PyCodec_Decode(buffer, encoding, errors);

[Nick Coghlan]

Post by antoine.pitrou
+/* The struct is declared here so that macros can work, but it shouldn't
+ be considered public. Don't access those fields directly, use the macros
+ and functions instead! */
+typedef struct {
+ PyObject_HEAD
+ PyObject *base;
+ Py_buffer view;
+} PyMemoryViewObject;

If we don't want people to use this struct directly, we should start the
name with an underscore.

Cheers,
Nick.

[Antoine Pitrou]

Post by Nick Coghlan

Post by antoine.pitrou
+/* The struct is declared here so that macros can work, but it shouldn't
+ be considered public. Don't access those fields directly, use the macros
+ and functions instead! */
+typedef struct {
+ PyObject_HEAD
+ PyObject *base;
+ Py_buffer view;
+} PyMemoryViewObject;

If we don't want people to use this struct directly, we should start the
name with an underscore.

Well, they can use it as an opaque pointer (PyMemoryViewObject *), just not
access the fields directly. I don't know what the convention should be in that
case, but feel free to make the necessary changes.

cheers

Antoine.

[Nick Coghlan]

Post by Antoine Pitrou

Post by Nick Coghlan

Post by antoine.pitrou
+/* The struct is declared here so that macros can work, but it shouldn't
+ be considered public. Don't access those fields directly, use the macros
+ and functions instead! */
+typedef struct {
+ PyObject_HEAD
+ PyObject *base;
+ Py_buffer view;
+} PyMemoryViewObject;

If we don't want people to use this struct directly, we should start the
name with an underscore.

Well, they can use it as an opaque pointer (PyMemoryViewObject *), just not
access the fields directly. I don't know what the convention should be in that
case, but feel free to make the necessary changes.

Ah, good point. What has been implemented seems fine then.

Cheers,
Nick.

[Georg Brandl]

Post by Antoine Pitrou

Post by Nick Coghlan

Post by antoine.pitrou
+/* The struct is declared here so that macros can work, but it shouldn't
+ be considered public. Don't access those fields directly, use the macros
+ and functions instead! */
+typedef struct {
+ PyObject_HEAD
+ PyObject *base;
+ Py_buffer view;
+} PyMemoryViewObject;

If we don't want people to use this struct directly, we should start the
name with an underscore.

Well, they can use it as an opaque pointer (PyMemoryViewObject *), just not
access the fields directly. I don't know what the convention should be in that
case, but feel free to make the necessary changes.

Well, logically it would be field names starting with underscores.

Just kidding,
Georg

[Nick Coghlan]

Post by Georg Brandl

Post by Antoine Pitrou
Well, they can use it as an opaque pointer (PyMemoryViewObject *), just not
access the fields directly. I don't know what the convention should be in that
case, but feel free to make the necessary changes.

Well, logically it would be field names starting with underscores.
Just kidding,

Heh, I almost wrote the same thing, but I stopped myself. That way lies
madness :)

Cheers,
Nick.