Changes by Pauli Virtanen :
--
pull_requests: +3286
___
Python tracker
<http://bugs.python.org/issue10746>
___
___
Python-bugs-list mailing list
Unsubscribe:
Pauli Virtanen added the comment:
Created backport PR for 3.6: https://github.com/python/cpython/pull/3241
Which versions take backports?
--
___
Python tracker
<http://bugs.python.org/issue10
Changes by Pauli Virtanen :
--
pull_requests: +3284
___
Python tracker
<http://bugs.python.org/issue10746>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Pauli Virtanen:
It's unclear if PyObject_CallFinalizerFromDealloc is a public function
or not. It is not documented, but it seems there's no other way to
ensure that tp_finalize runs, at least for objects without
Py_TPFLAGS_HAVE_GC.
In the documentation of t
Pauli Virtanen added the comment:
Converted patch to Github PR + some cleanup.
--
pull_requests: +61
___
Python tracker
<http://bugs.python.org/issue10
Pauli Virtanen added the comment:
Yes, this is a bug in numpy.linalg --- the GIL is released but the error
handling code assumes it's not. The error doesn't appear with in typical LAPACK
installations, so this code branch was missed.
--
Pauli Virtanen added the comment:
The array notation is useful for arrays inside structs, such as "T{(4)i(2,3)f}".
--
___
Python tracker
<http://bugs.python.o
Pauli Virtanen added the comment:
The flags don't seem to be meant to describe the properties of the buffer, only
what the exporter is required to fill in. STRIDES does not imply necessarily
discontinuous, only that the `strides` field is present. The
C_/F_/ANY_CONTIGUOUS flags imply
Pauli Virtanen added the comment:
@skrah:
Ahh, this always happens when I don't run it :) But my point stands -- the
reason why it does not crash with Numpy is that Numpy calls
PyMemoryView_FromObject to obtain a new memoryview and then uses
PyMemoryView_GET_BUFFER. Along this code
Pauli Virtanen added the comment:
@skrah:
Yes, Numpy exposes only a single buffer per object. Making this a requirement
in the PEP would probably be a sane change, as there is probably little
real-world need to allow it behave otherwise.
Comment on the patch: it seems you do not track the
Pauli Virtanen added the comment:
Lenard Lindstrom writes:
> Using Python reference counting and the garbage collector to control
> when PyBuffer_Release is called has problems.
That's not what's being suggested. The refcounting discussed here is an
implementation de
Pauli Virtanen added the comment:
skrah writes:
> I think slicing (esp. multidimensional slicing) would be greatly
> simplified if we added a requirement for the *exporting* object
> to provide a sliced view. (The same applies to sub-views, also
> see source comments below [1]).
>
Pauli Virtanen added the comment:
Nick's plan of action above seems mostly OK to me.
Though, it might be simpler to collapse the PyManagedBuffer object to
PyMemoryView, even if this requires memoryviews to serve two purposes.
[Nick:]
> I'm still not comfortable with a conventio
Pauli Virtanen added the comment:
Ok, here's a patch with some suggested documentation changes + the minimal
changes in memoryview to make bf_releasebuffer behave as advertised. Probably
shouldn't be applied as-is, though.
Problems remain. Suppose `bf_getbuffer` for memoryview is i
Pauli Virtanen added the comment:
Ok, good, that diversion was then avoided :)
***
So, am I on the right track that there would not be many objections to
clarifying the docs of Py_buffer spec by stating:
- For each buffer yielded by `bf_getbuffer`, `bf_releasebuffer`
is called exactly
Pauli Virtanen added the comment:
[clip]
> This is a different issue.
It is the issue relevant for this discussion. As written in my comment: "So,
`bf_releasebuffer` cannot rely on (i) the data in Py_buffer being what
`bf_getbuffer` put there, and (ii) getting the same Py_buffer d
Pauli Virtanen added the comment:
> Hmm, there's a misunderstanding. bf_releasebuffer is called exactly
> once for each call to bf_getbuffer.
Wrong: http://bugs.python.org/issue7433
static int
memory_getbuf(PyMemoryViewObject *self, Py_buffer *view, int flags)
{
Pauli Virtanen added the comment:
Hi,
Please focus on the constraints of the consumer not mucking with the content of
`Py_buffer`, and calling `bf_releasebuffer` only with data obtained from
`bf_getbuffer` and only one. If we agree on this, then how to exactly to do the
implementation is
Pauli Virtanen added the comment:
I spent today some time to rewrite `memoryobject.c`, and cleaning up the
Py_buffer handling in it. (I wrote also the Numpy PEP 3118 implementation, so
this was straightforward to do.)
The end result is here: https://bitbucket.org/pv/cpython-stuff/changesets
Changes by Pauli Virtanen :
--
assignee: -> theller
components: +ctypes
nosy: +theller
type: -> behavior
versions: +Python 3.1, Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/i
New submission from Pauli Virtanen :
Currently on Python 3.x:
>>> import ctypes
>>> memoryview(ctypes.c_long()).format
'http://bugs.python.org/issue10744 ):
>>> import numpy as np
>>> from ctypes import *
>>> class Point(Structure
New submission from Pauli Virtanen :
Ctypes arrays have invalid buffer interface information (on Python 3.1.2):
>>> import ctypes
>>> x = (ctypes.c_double*2)()
>>> y = memoryview(x)
>>> y.shape
(2,)
>>> y.format
'(2)http://projects.scipy.or
Pauli Virtanen added the comment:
> I still like the idea of scoped endianness markers in the substructs,
> but if we have to abandon that for compatibility with NumPy that's
> okay.
That, or change the Numpy implementation. I don't believe there's yet much code
in t
Pauli Virtanen added the comment:
For reference, Numpy's PEP 3118 implementation is here:
http://github.com/numpy/numpy/blob/master/numpy/core/_internal.py#L357
http://github.com/numpy/numpy/blob/master/numpy/core/src/multiarray/buffer.c#L76
It would be a good idea to ensure that the
New submission from Pauli Virtanen :
The C-API exposed by the `io` module on Python 3.1/3.2 is very limited, and
makes interfacing with Python file objects in extension modules difficult.
In more detail:
1) Because the Python layer has buffering etc., the file handle returned by
Pauli Virtanen added the comment:
I think this is an implementation issue in MemoryView rather than an
issue with the buffer interface. PEP 3118 states, "This same bufferinfo
structure must be passed to bf_releasebuffer (if available) when the
consumer is done with the memory." -- t
Pauli Virtanen added the comment:
> Why do you say that:
>
> > There is no feasible way the bf_releasebuffer can keep track of how
> > many calls to it have been made.
I was probably thinking about allocating new temporary arrays for
strides etc. on each *_getbuffer -- if
Changes by Pauli Virtanen :
--
type: -> crash
___
Python tracker
<http://bugs.python.org/issue7385>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Pauli Virtanen :
--
type: -> crash
___
Python tracker
<http://bugs.python.org/issue7433>
___
___
Python-bugs-list mailing list
Unsubscri
New submission from Pauli Virtanen :
The following code causes a segmentation fault (or glibc error, or other
problems):
>>> x = someobject()
>>> y = memoryview(x)
>>> z = memoryview(y)
The problem is that someobject.bf_releasebuffer will be called two times
New submission from Pauli Virtanen :
In Objects/memoryobject.c:PyMemoryView_FromObject there's a
_PyObject_GC_UNTRACK unpaired with corresponding _PyObject_GC_TRACK,
which seems to cause a segmentation fault. This can be triggered by
calling PyMemoryView_FromObject on an object
New submission from Pauli Virtanen <[EMAIL PROTECTED]>:
LaTeXTranslator.visit_footnote_reference generates improper Latex if
the footnote marker given is not a number. This will result in a Latex
error if the RST document contains footnotes where the marker is not a
number.
The prob
Pauli Virtanen <[EMAIL PROTECTED]> added the comment:
Thanks, works OK.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3422>
___
___
Python
Pauli Virtanen <[EMAIL PROTECTED]> added the comment:
Suggested patch attached. Tested on Numpy documentation.
It adds a new signal,
autodoc-process-signature(app, what, name, obj, options,
signature, return_annotation)
which is assumed to return eithe
New submission from Pauli Virtanen <[EMAIL PROTECTED]>:
It would be useful if the
autodoc-process-docstring
event from sphinx.ext.autodoc allowed to change the argspec of the
function being documented. Some other hook for changing the function
signature would also do.
We are
35 matches
Mail list logo
