A Standard

[Jay O'Connor]

In article <yu99u1biqu2z.fsf at europa.research.att.com>, "Andrew Koenig"
<ark at research.att.com> wrote:

> Erik> It seems to me that such abstraction layers are already inherent
> in Erik> Python, due to Python's dynamicism.  The documentation talks
> about Erik> "sequence types" and "mapping types," acknowledging full
> well that these Erik> describe _interfaces_ that non-builtin types can
> emulate and replace Erik> builtin types whenever a sequence object,
> rather than a specific type Erik> (e.g., tuple or list), is required.
> 
> Erik> To implement an object that implements the sequence interface,
> just Erik> create a class that has a __getitem__ method which returns
> meaningful Erik> values for 0 .. n - 1, and thereafter returns
> IndexError (there are of Erik> course further elaborations on the
> interface which can be used, which Erik> will).
> 
> What I see in this description is that the Python notion of "sequence
> types" is decidedly non-sequential, because __getitem__ really takes an
> arbitrary index as input.  So what Python calls a "sequence type" is
> closest to the C++ notion of a random-access iterator, except that you
> cannot offset such an iterator by an integer to obtain a new iterator.
> 
> Such differences can have surprisingly profound effects on programs.


I thought a Python 'sequence type' was closer to a C notation of an array?
  You can iterate sequentially over a sequence type, but a sequence type,
but that's really a linear wrapper using a random access mechanism


-- 
Jay O'Connor
http://www.r4h-music.com

"God Himself plays the bass strings first,
when He tunes the soul"