That is an entirely different discussion, Michael.
I do not know what ideas Guido had ages ago and where he might stand now and I actually seriously disagree with the snippet you quoted below. Python was started long ago as a way to improve in some ways on what was there before. Some of the ideas were nice but also for some purposes, way too slow. If you regard the original versions of LISP, they too simplicity to an extreme and pretty much the main or even only data structure was a list. Functions like CAR and CDR accessed an element but a complex structure resulted in people creating functions with names like CAAAAAR and CADADADR to automate climbing a tree of sorts to get to the parts you want. It was a recipe for complexity and errors. My point was that although a list can do so many things in principle, it is not really optimized to do some things that can be way easier using add-ons or your own data structures like objects and he notes the collection library and deque as an example that he is not as much of a purist as you may think. My point was that if you have a fairly detailed and complex application that will manipulate lots of data, then instead of reading in a CSV with many columns and rows recorded into a list of lists, it may make sense to import numpy and pandas that come with all kinds of functionality built in so you do not need to re-invent everything. Just how easy is it using lists of lists to rearrange the order of columns of data, or add new columns containing calculations built from existing columns and so on? Of course, for many purposes, it is indeed overkill albeit once you learn a method, ... I think part of the design of Python, and this is just my guess, included going away from overly specific things done in earlier compiled languages and making it more abstract and inclusive. Arrays or vectors or other such names would normally require everything to be of the same data type and with a fixed length. The list data structure loosened this up quite a bit and also allowed lists within lists. That is great and for some purposes, not very efficient and especially not when your data actually is all of the same type or of fixed length. You can make matrix-like data structures of any depth using lists and it may be hard to traverse such as when you want to multiply two such 2-D matrices. Place the same data (all say floating point numbers) in a vector-like structure that also has stored info about the dimensions, and a simple mathematical calculation accesses any item such as may_tricks[5,42] in the same amount of time as an offset from the top. I have seen this phenomenon in many languages where a somewhat clean and sparse design gets added to, often by others, until some core features are used less often. An example would be R which does have lists nut they are just one form of vectors which are really more the core data idea. It also contains data.frames in the core which are implemented as a list of vectors and more recently a bit more. It was designed to do statistical tasks as one of the main objectives. Yet the graphics functions have been added to so there are by now quite a few independent ways to make graphics using different paradigms. Python also has something like that. And completely new paradigms such as piping data in a chain were added in packages and it became so popular that a version has been added to the core language. Now although the core language includes lots of the functionality you might see in numpy/pandas and you can do all kinds of things, some others kept creating new ways to do things including different data structures that either dealt with weaknesses found or were ore efficient and so on and an entire growing body of alternate ways to do things with lots more power and often more speed that I prefer. A collection of lots of these alternative packages has been assembled and I and others often simply start programs by including the "tidyverse" and the resulting programs might as well be written in a different language to anyone who only knows base R. But I do not see that as a bad thing albeit someone trying to get a part of a program from an AI-like service may need to specify or they may get code they cannot trivially read and evaluate but that works fine once they have loaded the packages. Guido is like many others who create or invent and do it in the way they are proud of. Why change it? But the reality is that first attempts are often done with lots of room for change and improvement. Now if you are teaching a course on Python basics, it may be a good idea to teach the basics and require students to only use in their homework what has already been taught. But if you get a job where the norm is to use modules like numpy, it makes sense to use the expanded language if it results in faster writing perhaps of faster code with fewer mistakes. -----Original Message----- From: Python-list <python-list-bounces+avi.e.gross=gmail....@python.org> On Behalf Of Michael F. Stemper via Python-list Sent: Saturday, November 25, 2023 9:32 AM To: python-list@python.org Subject: Re: RE: Newline (NuBe Question) On 24/11/2023 21.45, avi.e.gr...@gmail.com wrote: > Grizz[l]y, > > I think the point is not about a sorted list or sorting in general It is > about reasons why maintaining a data structure such as a list in a program > can be useful beyond printing things once. There are many possible examples > such as having a list of lists containing a record where the third item is a > GPA for the student and writing a little list comprehension that selects a > smaller list containing only students who are Magna Cum Laude or Summa Cum > Laude. > > studs = [ > ["Peter", 82, 3.53], > ["Paul", 77, 2.83], > ["Mary", 103, 3.82] > ] I've seen Mary, and she didn't look like a "stud" to me. > Of course, for serious work, some might suggest avoiding constructs like a > list of lists and switch to using modules and data structures [...] Those who would recommend that approach do not appear to include Mr. Rossum, who said: Avoid overengineering data structures. Tuples are better than objects (try namedtuple too though). Prefer simple fields over getter/setter functions... Built-in datatypes are your friends. Use more numbers, strings, tuples, lists, sets, dicts. Also check out the collections library, eps. deque.[1] I was nodding along with the people saying "list of lists" until I reread this quote. A list of tuples seems most appropriate to me. [1] <https://gist.github.com/hemanth/3715502>, as quoted by Bill Lubanovic in _Introducing Python_ -- Michael F. Stemper This sentence no verb. -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
