Newline (NuBe Question)

[DL Neil]

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.gross at 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