[Cython] Cython 0.16

mark florisson markflorisson88 at gmail.com
Sat Oct 29 19:44:07 CEST 2011


On 29 October 2011 18:05, Robert Bradshaw <robertwb at math.washington.edu> wrote:
> On Sat, Oct 29, 2011 at 4:41 AM, mark florisson
> <markflorisson88 at 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.seljebotn at 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 at python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>


More information about the cython-devel mailing list