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.
I think virtually noone are using the object[...] at the moment, and
better remove backwards compatability sooner than later.
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...).
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.
>> 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 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.
(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.)
--
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
