On Jun 9, 2009, at 12:46 AM, Dag Sverre Seljebotn wrote:
> Robert Bradshaw wrote:
>> On May 21, 2009, at 11:16 AM, Dag Sverre Seljebotn wrote:
>>> However this creates some syntax issues:
>>>
>>> A) Currently
>>>
>>> cdef object[int] arr = ...
>>>
>>> can be used for PEP 3118 access on a generic object. While not a
>>> technical problem (object will never become a template), it looks a
>>> bit
>>> odd when introducing with a template feature.
>>>
>>> B) How would a templated buffer type look like? MyType[int][float]?
>>>
>>> Proposal:
>>>
>>> The object[int] syntax is removed (are anyone using it?).
>>
>> It's a good idea to have a non-conflicting syntax like int[:], but I
>> don't think we should be treating ndarray[int] and object[int] any
>> differently, or removing backwards compatibility.
>
> The idea here is that given templates the object hierarchy will look
> like this:
>
> object
> |
> +-- SomeTemplate[int]
> |
> L-- ndarray[int]
>
> My idea is then that it will look nicer if object doesn't default to
> being a "template" as well.
>
> We could introduce a new decorator to make this point clear (at least,
> the following code will make clear how I'd prefer to think of it):
>
> @cython.buffer.auto_buffer_template(
> defaults={"ndim":2, "mode":"strided"})
> cdef class MyImage(object):
> ...
>
> with the understanding that Cython transforms this into
> cdef class MyImage[type, ndim=2, mode="strided"](object):
> ...
>
> with an efficient __getitem__/__setitem__ implementation.
>
> Making this behaviour the "default" template behaviour for a type,
> unless a template is explicitly requested, just seems more confusing.
cdef class MyImage[...](object):
would always be a template, not a buffer.
> I think virtually noone are using the object[...] at the moment, and
> better remove backwards compatability sooner than later.
I see your point, but I think explicitly disallowing object is too
inconsistent. It's also nice to not have to even cimport numpy to use
efficient buffer access and be able to handle anything that exports a
buffer interface.
> But, it's certainly a point where pragmatism might go before purism.
>
>>> This is basically done by making any cdef class with the
>>> __cythonbufferdefaults__ magic attribute become a "buffer template".
>>> Such cdef classes cannot be templates. Any other class cannot be
>>> used as
>>> a buffer-supporting object.
>>
>> Are you suggesting we require __cythonbufferdefaults__ for all buffer
>> classes? __cythonbufferdefaults__ doesn't make sense for, e.g.,
>> ndarrays.
>
> ? They are used in numpy.pxd already (and if removed, mode would
> default
> to "full", causing an extra if-test per dimension per access...).
Oh, you're right. I was thinking ndim couldn't be set, but there are
other things that can be.
> But I now like the above decorator -- but this would be the backwards
> compatability with most classes. Almost all serious uses must have set
>
> cdef __cythonbufferdefaults__ = {"mode": "strided"}
>
> anyway.
I'm OK with either the decorator of the __cythonbufferdefaults__.
>
>>> for generic access, without any object access (this means that
>>> for now
>>> only indexing and getting the shape is allowed at all.)
>>
>> I like the int[:] syntax, but I'm -1 on the raw buffer no-object-
>> access idea. Having to write
>>
>> cdef object foo = ...
>> cdef int[:] foo_buf = foo
>>
>> seems clunky to me--I really like that in the current system one
>> doesn't have to have to separate variables to access a buffer as a
>> fast array or a Python object--this fits in well with the whole
>> Cython philosophy. (I do think we should print warnings for people
>> who write A[i][j] (which is slower from Python too, and should be
>> obvious if cython -a is run).)
>>
>> I would rather see int[:] be a type qualifier (like long,
>> unsigned, ...) so one can write
>>
>> cdef int[:] object foo
>
> Hmm. I'm not against that -- would you then be ok with
>
> cdef int[:] foo
>
> not giving any object access at all? (The thing is I also want to
> use it
> to access arrays stored in C pointers etc.; + safe passing around of
> buffers in nogil mode!)
I could accept that, I trust that the details could be worked out
nicely. Would be like a char* from an object, where the user is
required to keep the object around long enough?
> I guess I see it as getting hold of another interface -- I see it this
> way: Objects supporting PEP 3118 kind of "inherits from" int[:]
> through
> multiple inheritance.
I see "providing X api/interface" and "inheriting from" as two
orthogonal concepts (though the two have historically been conflated
due to statically linked languages such as C++ and Java).
> (If doing something like this I'd rather like to adopt Guido's mock
> syntax for combining interfaces -- e.g. if a class implements both
> "Iterable" and "File" interfaces, one could do
>
> cdef Iterable & File foo
>
> Of course, Cython currently doesn't support multiple inheritance (even
> through Java interfaces), and we might not want to over-prepare for
> that. Meaning "cdef int[:] object foo" could work.)
Agreed. Also, we don't want the syntax to suggest that any two types
could be paired--there's something very different going on here.
- Robert
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
