github.com/numpy/numpy/issues
> that would be great. If you have time, also with some info about the platform
> and how to reproduce it. Or at least a link to the build logs.
For the second one there's an issue here:
http://projects.scipy.org/numpy/ticket/2193
Stefan Krah
Nathaniel Smith wrote:
> On Sat, Aug 4, 2012 at 11:42 AM, Stefan Krah
> wrote:
> > switch (descr->byteorder) {
> > case '<':
> > byteorder = -1;
> > case '>':
> > byteorder = 1;
;
}
args = Py_BuildValue("(N)", u);
if (args == NULL) {
return NULL;
}
u = type->tp_new(type, args, NULL);
Py_DECREF(args);
return u;
}
All newbyteorder() test have to be deleted of course. I also think that
ucsnarrow.c is no long
7;clean',
- 'install_clib',
'install_scripts',
'bdist',
'bdist_dumb',
'bdist_wininst',
]
+from numpy.distutils.command import install_clib
__im
ction, so no checks are done.
> As such, I think that my PR simply extends the numpy approach to Python 3.3.
Absolutely, I also think that using invalid Unicode strings in 3.2 looks kind
of hackish. -- Nothing wrong with your 3.3 implementation, it's the general
concept th
64
64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
in ../nptl/sysdeps/unix/sysv/linux/raise.c
(gdb)
This should be expected since the byte-swapped strings aren't valid.
Stefan Krah
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Stefan Krah wrote:
> > .python3.3: numpy/core/src/multiarray/common.c:161:
> > PyArray_DTypeFromObjectHelper: Assertion
> > `((PyObject*)(temp))->ob_type))->tp_flags & ((1L<<27))) != 0)' failed.
> > Aborted
>
> This also occurs with P
Stefan Krah wrote:
> Then there's another problem in numpy.test() if Python 3.3 is compiled
> --with-pydebug:
>
> .python3.3: numpy/core/src/multiarray/common.c:161:
> PyArray_DTypeFromObjectHelper: Assertion
> `((PyObject*)(temp))->ob_type))->tp_flag
Helper: Assertion
`((PyObject*)(temp))->ob_type))->tp_flags & ((1L<<27))) != 0)' failed.
Aborted
Stefan Krah
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
more useful if they did this.
Stefan Krah
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
+args = Py_BuildValue("(Os)", b, "utf-32");
+if (args == NULL) {
+Py_DECREF(b);
+return NULL;
+}
+obj = type->tp_new(type, args, NULL);
+Py_DECREF(b);
+Py_DECREF(args);
+return obj;
}
#endif
i
ble to drop Py_UNICODE altogether. For instance,
the line in
https://github.com/certik/numpy/commit/d02e36e5c85d5ee444614254643037aafc8deccc
should probably be:
itemsize = PyUnicode_GetLength(robj) * PyUnicode_KIND(robj)
Stefan Krah
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
might be a blocker: Python-3.3 will be released in August
and I don't think the issue is fixed yet:
http://projects.scipy.org/numpy/ticket/2145
Stefan Krah
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Stefan Krah wrote:
> Dag Sverre Seljebotn wrote:
> > Under 2), would it make sense to also export the contents of a
> > Fortran-contiguous buffer as a raw byte stream? I was just the other week
> > writing code to serialize an array in Fortran order to a binary stream.
&g
ow should the buffer be used if itemsize is set to 1? For example,
it seems impossible to implement tobytes() if the real itemsize is
missing.
Travis, if you have time, it would be very nice to have your input
on this one, too.
Stefan Krah
[1] format:
"a NULL-terminated format-string (f
Mark Dickinson wrote:
> On Mon, Aug 22, 2011 at 1:30 PM, Stefan Krah
> wrote:
> > Numpy arrays and memoryview currently have different representations
> > for shape and strides if ndim = 0:
[...]
> > I think the Numpy representation is nicer. Also, I think that memoryvie
that the new memoryview object has
a managed buffer that takes a snapshot of the original exporter's buffer
(See: http://bugs.python.org/issue10181).
Now, since getbuffer requests to the memoryview object cannot be redirected
to the original object, strict rules are needed for memory_getbuf().
ible
to change the representation in memoryview.
Travis, was the "shape is None" representation used for compatibility with
ctypes? Would it be possible or advisable to use the Numpy representation?
Stefan Krah
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
ding to the C-API docs
a consumer would be allowed to access buf[9], which would be invalid.
Or is a consumer supposed to observe ndim = 0 and treat the result
as a scalar? If so, there is a problem with this approach. For example,
19 matches
Mail list logo
