On 11/27/2023 10:04 AM, Peter J. Holzer via Python-list wrote:
On 2023-11-25 08:32:24 -0600, Michael F. Stemper via Python-list wrote:
On 24/11/2023 21.45, avi.e.gr...@gmail.com wrote:
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.
^^^^^^^^^^^^^^^
The key point here is *over*engineering. Don't make things more
complicated than they need to be. But also don't make them simpler than
necessary.
Tuples are better than objects (try namedtuple too though).
If Guido thought that tuples would always be better than objects, then
Python wouldn't have objects. Why would he add such a complicated
feature to the language if he thought it was useless?
The (unspoken?) context here is "if tuples are sufficient, then ..."
At recent PUG-meetings I've listened to a colleague asking questions and
conducting research on Python data-structures*, eg lists-of-lists cf
lists-of-tuples, etc, etc. The "etc, etc" goes on for some time!
Respecting the effort, even as it becomes boringly-detailed, am
encouraging him to publish his findings.
* sadly, he is resistant to OOP and included only a cursory look at
custom-objects, and early in the process. His 'new thinking' has been to
look at in-core databases and the speed-ups SQL (or other) might offer...
However, his motivation came from a particular application, and to
create a naming-system so that he could distinguish a list-of-lists
structure from some other tabular abstraction. The latter enables the
code to change data-format to speed the next process, without the coder
losing-track of the data-type/format.
The trouble is, whereas the research reveals which is faster
(in-isolation, and (only) on his 'platform'), my suspicion is that he
loses all gains by reformatting the data between 'the most efficient'
structure for each step. A problem of only looking at the 'micro',
whilst ignoring wider/macro concerns.
Accordingly, as to the word "engineering" (above), a reminder that we
work in two domains: code and data. The short 'toy examples' in training
courses discourage us from a design-stage for the former - until we
enter 'the real world' and meet a problem/solution too large to fit in a
single human-brain. Sadly, too many of us are pre-disposed to be
math/algorithmically-oriented, and thus data-design is rarely-considered
(in the macro!). Yet, here we are...
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list
