Mercurial > cpython-lru_cache-weakref
view Include/memoryobject.h @ 73323:dad02a080bbc
Improve byte-compilation in packaging to be independent of -O or -B.
The code I fixed to comply with PEP 3147 still had one bug: When run
under python -O, some paths for pyc files would be pyo, because I called
imp.cache_from_source without explicit debug_override argument in some
places, and under -O that would return .pyo (this is well explained in
the imp docs). Now all code (util.byte_compile, build_py, install_lib)
can create .pyo files according to options given by users,
without interference from the calling Python’s own optimize mode.
On a related topic, I also removed the code that prevented byte
compilation under python -B. The rationale is that packaging gives
control over the creation of pyc files to the user with its own explicit
option, and the behavior should not be changed if the calling Python
happens to run with -B for whatever reason. I will argue that this is a
bug fix and ask to be allowed to backport this change to distutils.
Finally, I moved one nugget of information about the --compile and
--optimize options from the source into the doc. It clears up a
misunderstanding that I (and maybe other people) had.
| author | Éric Araujo <merwok@netwok.org> |
|---|---|
| date | Thu, 03 Nov 2011 05:08:28 +0100 |
| parents | 8a302a09ee83 |
| children | 215690b782f8 |
line wrap: on
line source
/* Memory view object. In Python this is available as "memoryview". */ #ifndef Py_MEMORYOBJECT_H #define Py_MEMORYOBJECT_H #ifdef __cplusplus extern "C" { #endif PyAPI_DATA(PyTypeObject) PyMemoryView_Type; #define PyMemoryView_Check(op) (Py_TYPE(op) == &PyMemoryView_Type) #ifndef Py_LIMITED_API /* 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) #endif PyAPI_FUNC(PyObject *) PyMemoryView_GetContiguous(PyObject *base, int buffertype, char fort); /* Return a contiguous chunk of memory representing the buffer from an object in a memory view object. If a copy is made then the base object for the memory view will be a *new* bytes object. Otherwise, the base-object will be the object itself and no data-copying will be done. The buffertype argument can be PyBUF_READ, PyBUF_WRITE, PyBUF_SHADOW to determine whether the returned buffer should be READONLY, WRITABLE, or set to update the original buffer if a copy must be made. If buffertype is PyBUF_WRITE and the buffer is not contiguous an error will be raised. In this circumstance, the user can use PyBUF_SHADOW to ensure that a a writable temporary contiguous buffer is returned. The contents of this contiguous buffer will be copied back into the original object after the memoryview object is deleted as long as the original object is writable and allows setting an exclusive write lock. If this is not allowed by the original object, then a BufferError is raised. If the object is multi-dimensional and if fortran is 'F', the first dimension of the underlying array will vary the fastest in the buffer. If fortran is 'C', then the last dimension will vary the fastest (C-style contiguous). If fortran is 'A', then it does not matter and you will get whatever the object decides is more efficient. A new reference is returned that must be DECREF'd when finished. */ PyAPI_FUNC(PyObject *) PyMemoryView_FromObject(PyObject *base); #ifndef Py_LIMITED_API PyAPI_FUNC(PyObject *) PyMemoryView_FromBuffer(Py_buffer *info); /* create new if bufptr is NULL will be a new bytesobject in base */ #endif /* 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! */ #ifndef Py_LIMITED_API typedef struct { PyObject_HEAD Py_buffer view; } PyMemoryViewObject; #endif #ifdef __cplusplus } #endif #endif /* !Py_MEMORYOBJECT_H */
