On 29 October 2011 18:05, Robert Bradshaw <rober...@math.washington.edu> wrote: > On Sat, Oct 29, 2011 at 4:41 AM, mark florisson > <markflorisso...@gmail.com> wrote: >> Hm ok I'll disable them then. Pointers and some other dtypes are also >> not supported yet. As for the documentation, have you guys reviewed >> the documentation for fused types and memoryviews? > > I looked at the fused types docs. > >> For instance this >> is the introduction for memoryviews: >> >> " >> Typed memoryviews can be used for efficient access to buffers. It is >> similar to the current buffer support, but has more features and >> cleaner syntax. A memoryview can be used in any context (function >> parameters, module-level, cdef class attribute, etc) and can be >> obtained from any object that exposes the PEP 3118 buffer interface. >> " >> >> but I'm not sure this new functionality won't confuse users of the old >> buffer support. >> >> For fused types, cython.numeric only includes long, double and double >> complex. I think that should be changed to short, int, long, float, >> double, float complex and double complex. > > Yes. What about size_t, ssize_t, and Py_ssize_t?
Hmm, these things don't contain unsigned types as they may be chosen when calling directly (as they're longer), but they will cause problems for negative values. I think unsigned types should be explicit. I think size_t is also more for representing the size of objects, I'm not sure you'd want the same code operating on size_t and say, ints. Py_ssize_t is typically used as the type for indices, but not much else I think, so it might be weird to include it. >> I was deliberately avoiding >> long long and long double as they (if not used as a base type) would >> be preferred over the others and may be a lot slower. But then, such >> usage wouldn't be very useful. Should I include them then? > > That's a good question. Perhaps these two could be used if explicitly > requested, or for dispatching from a Python long (in Py2) or > non-word-sized int (in Py3). I'm not sure I understand, how would you request them explicitly? The user could always just created a fused type manually if he/she wants long long, long double, or long double complex. >> On 29 October 2011 10:30, Dag Sverre Seljebotn >> <d.s.seljeb...@astro.uio.no> wrote: >>> Re b), it would be better to disable object dtypes (or emit a warning about >>> the possible bug when using them) than to delay the release. Object >>> memoryviews are rare in the first place, and those who contain themselves >>> should be very rare. > > +1 to a warning, especially if the problem is only related to circular > references. Hmm, a warning, ok. Do we desperately want to get a release out, or do we want it for somewhere e.g. at the end of the week? Because fixing this issue wouldn't be too hard I think, and it might give us some more time to review and merge Vitja's code. super() is pretty neat. > - Robert > _______________________________________________ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel > _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
