On 29 October 2011 18:59, Robert Bradshaw <rober...@math.washington.edu> wrote: > On Sat, Oct 29, 2011 at 10:44 AM, mark florisson > <markflorisso...@gmail.com> wrote: >> 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. > > You're right about unsigned. > >> 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 thinking if one had > > cdef foo(integral x): > ... > > then foo[ssize_t] > > should be available, but perhaps not used implicitly. I suppose this > would be an exceptional case for dispatching, and > > cdef fused my_type: > integral > ssize_t > long long > > is easy enough for the user to do.
Ah, I see. Yeah, that's not implemented :P >>>> 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. > > No hurry, but I was thinking it'd be good to get the ball rolling and > get these features released. > > - 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
