[Cython] Cython 0.16
markflorisson88 at gmail.com
Sat Oct 29 20:03:16 CEST 2011
On 29 October 2011 18:59, Robert Bradshaw <robertwb at math.washington.edu> wrote:
> 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
> 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:
> 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.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
>> 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 at python.org
More information about the cython-devel