[Cython] Cython 0.16

[mark florisson]

On 29 October 2011 18:47, mark florisson <markflorisson88 at gmail.com> wrote:
> On 29 October 2011 18:44, mark florisson <markflorisson88 at gmail.com> wrote:
>> 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.
>
> Yes, I think the long long and long double ones should just be
> excluded. If people want them they can fuse their own types.
>
>>>> 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
>>>
>>
>

Maybe numpy.pxd could provide a numpy version of integral, floating
and numeric, that will contain all relevant numpy types.