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.com@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.gross@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
