[Tutor] Strengths & weaknesses of Python lists compared to "old school" arrays [Was "Fixed Vector Array"]

[Alan Gauld]

On 04/03/15 19:10, boB Stepp wrote:

> learned of programming via FORTRAN and BASIC (various incarnations).
> These used multidimensional array-based thinking.

> ... I don't recollect anything similar to Python lists

There weren't, and it was a common programming exercise to
create them using arrays and an API. This made sense since it 
demonstrated how to enrich the language with a superior
data structure. Unfortunately some courses seem to have
decided that its equally good to go from the rich lists
to simple arrays! Thus removing or replicating built in
functionality.

> those languages way back then. In doing physics-related programming it
> was not unusual to have a need for 3- or 4-dimensional arrays, and
> sometimes more.

That hasn't changed

> What are the strengths and weaknesses of Python lists compared to "old
> school" arrays?

This will be a somewhat subjective assessment because each programmers 
use cases will vary. My summary would be that in 17 years of using 
Python I've never felt the need of a traditional array.

It doesn't mean there aren't cases where they might have an edge,
but usually there is a more Pythonic solution. Such as using
a dictionary to create a sparse array simulation, or creating
a class.

>      1) If the data involved is strictly numerical, does this alter
> your answer? Especially if multidimensional matrix calculations are
> involved?

No. Numbers are just objects, there is no inherejnt advantage to using 
arrays v lists.

>      2) If either numerical or string data is allowed to be stored,
> does this change your answer?

Strictly speaking a traditional array is single typed so you can't have
strings and numbers mixed (although you could have an array of variant 
records which achieves the same.)

>      3) Have "old school" arrays evolved into something more flexible
> in most programming languages?

Yes, exactly that's why most modern languages (from about 1990 onwards) 
have native collection objects that work more or less like Python lists.
Either as a native data type or via a standard library.

>      4) Are there other clarifying questions I should be asking on this
> topic that are not occurring to me?

Issues such as performance (arrays are usually direct memory access) 
and resource consumption (simply memory block arrays with no extra 
pointers to maintain) enter into the picture. Also compatibility with 
other languages. An array is typically implemented as a simple block
of memory and so can be accessed from most languages. Lists tend
to be much more sophisticated structures requiring an API that
may not be (fully) supported in another language.

> What is a complete list of the "things" array-style thinking allow,
> but that Python lists don't? And for those "things", what would be a
> Python way of handling them?

Hmm, a "complete list" is hard to pinpoint. Especially since
there is nearly always a way round it. Also it depends on which language 
you are comparing to. For example C is almost optimised for native 
arrays with direct pointer access and pointer arithmetic allowing some 
very slick array handling tricks. But in BASIC those things are just not 
possible. So are we comparing Python lists
to BASIC arrays  (in which case Python wins nearly every time) or Python 
lists to C arrays, in which case C has several tricks up its sleeve. 
(Note Visual Basic arrays are much more sophisticated that vanilla BASIC 
arrays, they are more like Python lists)

Here are some typical concepts:

1) arrays are typically created at compile time so there is no 
initialisation cost. Similarly by being fixed size there is no 
performance cost in adding new members(up to the fixed size limit)

2) arrays can be empty and sparcely populated.
You cannot do this in Python:

array = [0,1,2,,,,,,8,9,,,12]

you need to specify None in the empty slots
But you can use a dictionary:

array = {0:0, 1:1, 2:2, 8:8, 9:9, 12,12}

But that's more cumbersome to create/maintain.
But its just as easy to use...

3) In some language you can create the array as single entities
but then use them in pairs or triples etc. In Python you need a 
combination of slicing and helper functions to do that. but
its a fairly esoteric case mainly, in my experience, used
for systems programming in segmented memory architectures.

4) Arrays as memory blocks can be quickly copied or moved or
dumped to disk/networks using byte level operations. This can
be important in high performance applications.

I'm running out of ideas here, I'm sure others will chip in
with more.

> wanted to address an item in a 3-dimensional array, I would use
> something like (x, y, z) whereas the Python list form amounts to
> [x][y][z] .

That's just a syntax thing, Python could have allowed single
bracketing of index, Guido chose to follow his mantra of explicit
is better than implicit. Many array based languages (including C)
also require multiple explicit indices.

> addressing pales in comparison to the power and flexibility of the
> "stuff" I can store in a list

Absolutely and that's why most modern languages, even when they have 
"arrays", are more like Python lists. And don't forget the other data 
collections in Python that used to have to be built in older
languages: dictionaries, sets, tuples, classes.

When combined these are far superior to managing multiple arrays: trying 
to keep indices in step, resizing when you need more space, inserting 
into the middle. sorting across multiple arrays etc.

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos