[Cython] Cython 0.16

[mark florisson]

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