On Mar 30, 2015, at 11:33 AM, Ian Foote <ian@feete.org> wrote:

On 30/03/15 16:05, Ian Cordasco wrote:

On Mon, Mar 30, 2015 at 9:59 AM, Daniel Holth <dholth@gmail.com> wrote:

Yes, setup.py should die. Flit is one example, and you can understand
it not by copy/pasting, but by spending half an hour reading its
complete source code.

In other words, no one should read the docs because that's a waste of time? Because a lot of time has been poured into the packaging docs and if they're not sufficient, then instead of improving them, people should write undocumented tools that force people to read the source? I'm not sure how that's better than what we already have.

You're attacking a strawman. Flit does have documentation. What Daniel was trying to say is that flit is small enough to understand by just reading the source code.

The size of the code base isn’t an interesting discriminator in judging quality. Python does not try to be a language that minimizes the number of lines of code and when looking at straight SLOC (in abstract of these two projects) it’s entirely possible to have something harder to understand with less SLOC and easier to understand with more. In particular looking at these two pieces of software, trying to compare SLOC is even more silly given the two toolchains don’t even come close to the same feature set.

Ian C, is pointing out that being able to understand it “just by reading the source code” (whatever that means, what software can’t you understand by reading the source code?) isn’t an extremely useful discriminator either because it’s premised on the fact that there is going to be a common situation where you *need* to read the source code to understand it. So the statement is in itself not particularly useful because it’s premised on something that is fundamentally user hostile. An end user shouldn’t care if it’s written in 600 lines, 6000 lines, or 6 million lines. What matters to them is the interface it provides and the documentation around it and often the “ease” of reading the code is used to excuse poor (or non existent) documentation.