Hacker News Reader

"Array" is a pretty loosely defined term that varies from language to language. Python lists are what you may know as "variable-length arrays" of python objects (in other words: not type constrained). If you want type-constrained arrays, you'll use the array module: https://docs.python.org/3/library/array.html

that w3schools page is indeed nonsense. They should probably stick to JS.

Python lists may well be implemented as arrays. I don't know if they are or not, as I haven't read the Python interpreter source code.

If they are, then the article is even worse, as the disclaimer that Python doesn't have arrays is a lie!

Everything in Python is implemented as a dict behind the scenes, which is implemented in C with a few different types. Python does have arrays in the standard library's array module, so yes saying python doesn't have arrays would be a lie.

It depends on how strictly one defines "array." If you mean it generically as "an indexable contiguous memory buffer containing the actual data being indexed," pretty sure Python lists don't comply even at a mechanical level.

While the Python 3 docs for arrays certainly do lean on the type-constraint, I notice it also has the various operations that imply a contiguous buffer (cast to bytes, etc.), so I wonder if that's not the real distinction and the type constraint serves that.

Traditional Python lists are much closer to what I know as a vector: indexable like an array, but dynamically expandable and usually implemented as a list of references to data structures instead of containing the data itself so allows for heterogenous data.

Informally, I've certainly called both types of things arrays, right or wrong, and rarely call anything a vector other than container classes by that name, but I do suspect that's what your parent comment is drilling on.

* Then there's the JS Array class, which acts more like a vector than array by those definitions, so who knows.

I'd be angry at python there. It's python that uses lists like arrays in the standard language, making beginners search for arrays when python would use a list.

That's a pattern of the language and why I don't like it: It's very often almost like the other C-like languages, only to be that much different that it gets confusing. To just ignore that and call a list an array is not correct, but it makes the beginner searching how to do array-like stuff in python succeed in his task.

I'd be more annoyed at that page if they didn't explain the situation, but they do.

> I'd be more annoyed at that page if they didn't explain the situation, but they do.

Actually, they don't. The article claims that arrays don't exist, but you can use lists instead.

Apparently the polar opposite is true: lists don't exist, but you can use arrays instead! (And they're called "lists" for whatever reason).

This is silly. Both "list" and "array" are so broadly defined that they largely overlap.

Then why doesn’t the article point out what definitions it’s using, rather than claiming arrays don’t exist and then talking about arrays?

Python has something it calls lists. Those lists are basically like what other languages would call arrays.

But python also has an array module you can use after an import, it's not loaded by default. That data structure behaves even more like the thing C calls an array.

I don't see why a python list is not a list per se. Don't be confused by the others explaining it is not a linked list - something does not have to be a linked list to be a list. It's still a numbered collection of stuff that can be sorted, thus a list.

Though it is true that as a programmer you probably are first confronted with a data structure called list when you learn a LISP, and that data structure will be a linked list.

Confronting beginners with all this is not useful for them, w3schools just adding a note and calling the python default collection thing an array is thus not that unreasonable. Though I'd prefer it if they just called it a list in the explanation below the note, after explaining that this list structure is what you are probably searching, with a link "look there for what python calls an array". So in that way I agree with you, this is not optimal.

Python lists do the job of an array probably for 99% of cases. Depends on your exact definition of an array and if that even matters

The subway does the job of a car in 99% of cases. Doesn't mean they're the same thing. I also wouldn't appreciate an article about subways with the title "Cars".

I have literally never seen or heard of a definition of array according to which lists are arrays -- can you cite one?

Can you cite a common definition of “array” other than a bare minimum of being randomly accessible? (Nothing else is pinned down. Fixed vs variable length, single vs mixed type, or even underlying data structure (cf NSArray)).

By the only universal definition I can think of, python lists are arrays.

Python lists most certainly meet the mathematical definition of array (ie name by index)

It seems you're right. Python lists are arrays -- I didn't know that.

That makes my point even stronger. The article about "Python Arrays" directly claims that Python Arrays don't exist, which is apparently wrong!

The whole point is that I came away from the article believing information that is false.

Arrays are commonly an implementation, while lists are the mathematical or logical structure.

Same as how a hashtable is used to implement a mapping.

As always, as you say, it depends on your definition.

One of the useful definitions of an array is that it guarantees contiguous storage in memory. In Python, there is no way to guarantee that; even if a list is a C array of Python references under the hood, there's no way to store the information represented by those references contiguously in memory. From that perspective, pure Python doesn't have any arrays at all, which is precisely why the popular NumPy has to offer explicit support for numeric arrays.

From another perspective, arrays are a set of O() guarantees for various operations. From that perspective, Python lists will generally meet the specifications that you'd write for a resizable array, or perhaps what you might call "vector", depending. CPython comes with some awful constant factors but the O() of the lists will be what you'd expect.

Rather than arguing about whether Python has "arrays" interminably, it's better to carefully define array, then dispassionately examine Python lists to see if they match that definiton. You'll get a yes sometimes and no others. I say "dispassionately" because too many people seem to assign moral qualities to whether or not something conforms to a given definition, but that's not a path to understanding. No matter what definition you write down for "array", not a single characteristic of Python will change.

Python lists are dynamic arrays, not linked lists.

Then why does the article incorrectly claim that Python doesn't support arrays?

The whole point of my comment is that I went away from the article still not knowing whether Python has arrays, or not. I can't understand how anyone would defend an article called "X" that doesn't even properly inform you whether X exists

The article is not even wrong. That first yellow highlight is … ugh.

If a programmer from another language asks for an array, I'm going to point them at the `list` class in Python.

As some other sub-comments under your original post note, some uses of an array want the actual data to be contiguous. But Python `list`'s values are references to other values, not the direct values themselves. If you're familiar w/ C, it's closer to an array of pointers to objects. That matters for some niche cases. But in basic tutorial? No. And Python has some built-in types to account for some of the niche cases. Sure, that pointer is not free, and the overhead of a Python object is not free, but Python is a high level scripting language, and generally, `list` provides a random-access ordered collection, which is what most people want when they say "array", and the overhead doesn't matter for many things.

Python's list type is implemented as a dynamic array in CPython. This is not required.

An optimizing Python doing escape analysis could see a list was going to be converted to a set and swap in a set and change the method calls. Or it could see a large number of concatenations and use a linked list as an intermediate form.