It does? I think that actually makes it less clear what lists in Python are actually good or bad for. I think thinking of them in terms of a linked list in C is a much better abstraction.
In general, in a discussion about or adjacent to programming language design, people will tend to expect 'list' to be used to mean a data structure that behaves like a singly linked list ala lisp's cons cell based list data structures.
The programming styles list-first and array-first languages encourage are sufficiently completely different that using them interchangeably tends to be a really bad idea, and honestly python's arrays being named that way irritates me even if I don't consider 'this irritates me' to be a criticism per se.
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.
I don't see any problem with using "list" to refer to any data structure that is functionally equivalent to a list, regardless of implementation. This is hardly unique to Python: Mathematica's List type (despite the Lisp heritage) is also really an array.
You could easily imagine the implementation being changed to something else (say a VList or unrolled linked list) if someone did some benchmarking and it turned out that it made Python programs 5% faster on average. Then the name "array" would no longer be accurate, and neither would "list" in the narrow, pedantic sense. So using the term "list" in a more abstract sense is perfectly reasonable.
The term "list" also has some (tiny) advantages: it's shorter than "array" or "vector", and it's one less technical term for people learning programming (as I understand, this was one of Guido's design goals).
If we're going to talk about inaccurately named data types, let's start with the ubiquitous use of "integer" to refer to bastardized integers modulo 2^32...
>>> x = [[3, 4], 5]
>>> y = [6, x[0]]
>>> y[1][1] = 7
>>> x
[[3, 7], 5]
Octave and Tcl are the exceptions here, and of course in Racket (and maybe in Clojure?) the pointer semantics aren't visible as they are above, but do affect performance.
I like Python a lot (I edited the Weekly Python-URL for a while) but it took me longer to switch to it --- most of 2000 and 2001, really. I still occasionally reach for perl for quick command-line things.
You shouldn't write an article telling people not to use Python if you don't really understand Python in the first place. Lists are called Lists in Python because they are just that: lists of varying and dynamic length of heterogeneous datatypes. If you want an array with a homogeneous datatype packed efficiently sequentially in memory Python also has that: a=array('i').
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.
The reality is that Python lists usually work as serviceable queues and stacks. Criticizing a language for not having a standard queue or stack is a little weird.
Not a surprise. Python's `array` doesn't really do much, it just allows you to store and access homogenous data without wasting memory. That's all. It doesn't really deserve to be on this list.
I guess, but then it's also kind of uninteresting. Lists in Python are an array of pointers. That Python implements assignment differently is kind of an odd detail, but altering the value of one of the variables doesn't alter the value of the other. It's just sort of an under-the-hood implementation detail visible only through Python's introspection tools, not something that actually affects code. I tried it myself:
Correct. There's no such thing as a python a-list, or p-list, and they can't share structure. There's overlap between programming in Python with lists, and programming in Lisp with lists, but not as much as it appears.
In idiomatic Lisp, it's rather common to search a list for a value, cdr it, and cons that cdr to the collection you're building up. Python has nothing like that, because what I said makes no sense in terms of Python lists.
True, and I like python list alot as it offer the ability to hold heterogenous objects and it's really flexible & simple. Just happened to using list the other day to cache a large 2d array, which turned out to be slow. Certainly, my implementation has room for improvement, and my comparison isn't straightly an apple to apple. Taken down the post n modifying. Thanks for the comment btw.
reply