zero-copy array slicing (and PEP 296)

Alex Martelli aleax at aleax.it
Wed Nov 20 03:37:13 EST 2002


Trevor wrote:

> Alex Martelli <aleax at aleax.it> wrote in message news:<bvyC9.29870>
>> Wouldn't it be simpler if your functions also accepted optional
>> parameters
>> for offset and size in bytes?  So the user could call
>> 
>> hash(bytes, 128)
>> encrypt(bytes)
>> encrypt(bytes, start, finish-start)
>> 
>> ...?
> 
> Yeah, I could do that.  But if the language handled this it would
> simplify the function interface and my code (I wouldn't need to check
> for indexing errors, for example), and I could give users the more
> familiar slice syntax.
> 
> I noticed that PEP 296, for a 'bytes' type, would do just what I want.
>  I wonder how that's coming, and if it might be part of Python 2.3...

Might be, but do you want to _require_ 2.3 as a prereq for using
your extension?  That's much more serious than requiring Numeric,
which after all anybody could download and install even today - it
will be ages before 2.2 is replaced everywhere with 2.3, and that's
starting from when 2.3 definitive is out, and when will THAT be?
There is absolutely no deadline pressure on 2.3 -- it will come when
it's right.  And what if bytes doesn't make it into 2.3...?

If "giving the familiar slice syntax" is crucial you may expose a
type of your own, call its factory 'wrap' for example, and accept
both of the forms:
    wrap(bytes, start, finish-start)
    wrap(bytes)[start:finish]

That's STILL handier than what you were asking for in the first
place, which did NOT as you had hypothesized it support slice
syntax -- it was something like bytes.subsequence(start, finish).


Me, I'd go with Numeric -- partly because it defies belief that
somebody may need encryption and the like and NOT need some of
the many other conveniences Numeric offer (I have not yet done
any evaluation of whether the time is ripe to use Numarray in
lieu of Numeric -- that's a separate choice).


Alex




More information about the Python-list mailing list