Barry,
I am not going to continue replying in this thread. I made my point and it was focused after a while on the size of the CODE. Of course, the code can be made ever smaller using gimmicks and yet run longer or use more memory or CPU. If you have control of a package with a short name like "x" for example, you can write a function y() that builds in the code described or any variant and your program becomes: Import x y() and it would print out whatever you need. If you can get the python interpreter to make that module standard, it can be shorted more! As mentioned, one suggested metric for how complex a program is, or maybe how much information it contains, is the shortest program you can write to generate the info. Something already compressed may not be easy to make smaller. But the above idea does not care if the solution takes forever to run as in if it uses lots of tiny re-usable functions and does lots of recursion. Clearly, as has been pointed out, for many of the one-off programs people write here, optimization is not necessarily worthwhile. The program asked for here actually has minimal purpose as it does one thing that could be done in advance and replaced by a print statement. My "contribution" above does look stupid but consider what it would mean if the program asked you to print the first billion prime numbers. The program that simulated the output would likely read in huge file from disk and print it. The first part of the I/O might be much faster if the data on disk was compressed and if it could be uncompressed as it was being read and printed to the output, might be lots faster and even use less memory. Clearly it would likely use more CPU but far less than finding the first billion primes that hard way. Final note is there is not much in the discussion that is really about Python as much of the argument remains similar in many programming languages. So, I am done and will ignore this thread. From: Barry Scott <ba...@barrys-emacs.org> Sent: Thursday, June 24, 2021 3:12 PM To: Avi Gross <avigr...@verizon.net> Cc: python-list@python.org Subject: Re: Optimizing Small Python Code On 24 Jun 2021, at 16:58, Avi Gross via Python-list <python-list@python.org <mailto:python-list@python.org> > wrote: Now a has a length of 53! It now looks like this: b'x\x9c3\xe4R\x00\x03\x03.#8\x0bB\x1br\x19c\x88(\x18q\x99p!q\xc1\x00\xa6\xd1 \x98\xcb\x14S\x03\x9a\n\x13.3\x82j \xb4\t\x94\x86\x99\t\x00\xdc\x87\x14\xb7' So the shorter cheat program might now be: The data is smaller, but at the cost of the code that knows how to decompress it. I'd expect that by using compression you have increased memory use as this amount of data is far smaller than code to decompress it. Barry -- https://mail.python.org/mailman/listinfo/python-list
