Interests: News, Finance, Computer, Science, Tech, and Living
Compact does not mean easier to understand. They are different tests. The point is, do not make code less readable for speed unless speed matters. I am not going to argue which is more readable in any specific case. That is up to the developer.
By the way. The only files you mentioned I am less sure about are configs. Specifically if these configs are system specific, probaby only examples or templates should be included but the configs should be built by the build process on the target system.
Edit: It should contain tests. Running some equivalent to ‘make check’ on the target system is pretty standard.
Edit: Not sure what .github folder tree file contains so cannot say.
If your talking about a source distribution archive, generally it is the project in the ‘distclean’ state. This is decribed in GNU documentation. I think for GNU Make. Not sure if the git specific files should technically be included but maybe these days they should. The ‘distclean’ state is generally the same code as from the VCS tree but with hard to build files pre-built but probably not platform specific files. The ‘maintainerclean’ state is basically the clean VCS snapshot nothing pre-built.
Edit: The reason to prebuild some not platform specific files is to minimize the tools needed for installing from source.
I think you just like the truth test. Frankly I have used Python for over 25 years and have been doing programming for almost 50 years in many different languages. If you think I am somehow a beginner, I would disagree. The truth test is just like so many other Python specific idioms that grow in number by the year. They are not at all obvious unless you are deep into Python. Moreover, the truth test and the len() test are not the same test. One might be able to use either in a specific case, but that is case specific and which is more readable is up to the developer and we may well disagree on that choice. The other consideration in Python, speed of writing code which is often why many of us use Python and that may lead to different choices too including based on habit.
Lot of this reminds me of the Pascal vs. C debate of the 1980’s. Pascal was all about readability over compactness. C on the other hand, seemed to attract people that loved to write very compact code that was almost impossible to figure out on first glance. Me personally, I guess I’d choose C over Pascal but write the C in more of a Pascal authoring philosophy. Similarly, with Python, I often do not go for all of the Python idioms. Lot of that is just writing what I am thinking, and the rest is probably habit. If I am going to test 0 length then I’ll probably test zero length. I do not find it at all obvious that, oh, I want to test 0 length so the Python idiom for that is to truth test. I absolutely know that to be the case on certain types of objects, but it probably is not going to be my first choice.