[Cython] read-only memory views

[Robert Bradshaw]

On Tue, Sep 18, 2012 at 3:42 PM, mark florisson
<markflorisson88 at gmail.com> wrote:
> On 18 September 2012 20:55, Christoph Groth <cwg at falma.de> wrote:
>> Hello,
>>
>> I have written a python extension module, tinyarray, (to be made public
>> soon) which implements an important subset of numpy optimized for
>> _small_ arrays.  Tinyarrays are immutable, which makes them usable as
>> dictionary keys.
>>
>> Some important operations, i.e. creation of a small array from a tuple
>> or the scalar product of two small arrays are 10 to 45 times faster than
>> with numpy.  This can really boost the performance of programs which use
>> small numpy arrays.  (I know that numpy is meant to be used for large
>> arrays, but there are legitimate uses of small arrays as well.)
>>
>> It would be great if Cython could support tinyarrays.  Right now, it
>> doesn't.  See
>> http://article.gmane.org/gmane.comp.python.cython.user/7329
>>
>> (As a temporary workaround, I have to made the buffers writable.  But
>> this breaks strict immutability.)
>>
>> Would fixing this be a lot of work?
>
> That depends on how we implement it. A 'const' keyword has been
> discussed in general. This would be a little more work, since it needs
> grammar modifications. Also, there would be a difference between
> declaring the data and the variable const, i.e. 'const double[:]' vs
> 'double[:] const', which I personally find bothersome.
>
> Using flags are obvious, like the ones in cython.view, i.e.
> double[:view.readonly], but the problem with that is which axis to
> choose (or any axis?), and we don't have a way of combining flags. So
> we would not only need view.contiguous, but also
> view.contiguous_readonly etc.

I'd much rather be able to write view.readonly & view.contiguous than
come up with flags specifying the various permutations.

> Without a greater plan for 'const' I think it might be awkward to use
> for this purpose. I think the flags are apt, and should be used in the
> first dimension. If we wait for other people to comment we could give
> you pointers if you want to give implementing it a swing, it wouldn't
> be too hard.

Coincidentally, I actually implemented rudimentary const support a
couple of days ago. It's not perfect, but at least it allows you to
provide the correct declarations to deal with const polluted^H^H^H^H
correct code (including const c++ class methods, for which there was
simply no workaround). I just need to write some tests before I feel
comfortable pushing it.

That said, I think a flag is a good fit here, though const could work as well.

- Robert