[Cython] Cython 0.16

[Robert Bradshaw]

On Sat, Oct 29, 2011 at 10:44 AM, 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.

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.

>>> 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.

No hurry, but I was thinking it'd be good to get the ball rolling and
get these features released.

- Robert