> The single-file restriction is an effective save-guard against feature creep. [...] We are able reject pull requests simply because they would add too many lines or add too much complexity, and that's nice.
bottle.py is already 4425 lines of code [2].
So, despite they say they reject pull requests because they add too many lines, it's also can be said that they reject pull requests because file is too big already and merging PR makes it even harder to maintain.
> A single file is easier to debug and understand. [...] You can read the entirety of bottle.py in an hour or so. Most of it is pretty easy to understand. Try that with flask/pyramid/django [...]
Why not at least to just split it to 1 section per 1 file, which they emulate right now by using section-delimiting comments [3]? Will it make code much harder to understand? Or will it make code easier to understand?
Also, from a developer perspective, what about navigation to the correct section quickly. E.g. if developer wants to add a new Exception, how he can efficiently go to the specific section? If it wouldn't be single file, developer could jump to required file by typing couple of letters in fuzzy file opener it his editor of choice.
No one forces developers plunge into a feature creep apart from their own, and it actually doesn't matter is there a single file or not. Some prefer to write as many code as they can in one single line. I doubt that they do it to ease maintenance and to avoid feature creep.
I recon it is similar to the desire for header-only C libs, package management isn’t great, so single files are easier to deal with. I wonder if anyone has made a Python package manager based on the idea of bundling up all the files in a Python project into a single .py file that can just be downloaded and copied around as-is? No requirements.txt, just vendored .py files in a libs dir.
Header only c libs also emerge from c and c++ realities that are less true elsewhere.
The biggest one is the optimizer does a better job when stuff is in the same compilation unit. (Inlining and stuff.) A good example to look at is sqlite, which is developed as multiple files but they concatenate them together for distribution.
Another reason is a C++ one, and C is not C++ but the community has enough overlap that I think it tends to spill over. And that is templates. Templates need to be in the header so a lot of c++ libraries have complicated, slow to compile headers.
I do think, for example when any given person on HN links to a header only C or C++ library, that a lot of these people are overdoing it. They have likely not measured it and found it to be better like the sqlite people. They are fighting, perhaps even misunderstanding the tooling, at the cost of compile times and large binary sizes. And for what? Makefiles are not really that hard to write.
> The single-file restriction is an effective save-guard against feature creep. [...] We are able reject pull requests simply because they would add too many lines or add too much complexity, and that's nice.
bottle.py is already 4425 lines of code [2].
So, despite they say they reject pull requests because they add too many lines, it's also can be said that they reject pull requests because file is too big already and merging PR makes it even harder to maintain.
> A single file is easier to debug and understand. [...] You can read the entirety of bottle.py in an hour or so. Most of it is pretty easy to understand. Try that with flask/pyramid/django [...]
Why not at least to just split it to 1 section per 1 file, which they emulate right now by using section-delimiting comments [3]? Will it make code much harder to understand? Or will it make code easier to understand?
Also, from a developer perspective, what about navigation to the correct section quickly. E.g. if developer wants to add a new Exception, how he can efficiently go to the specific section? If it wouldn't be single file, developer could jump to required file by typing couple of letters in fuzzy file opener it his editor of choice.
No one forces developers plunge into a feature creep apart from their own, and it actually doesn't matter is there a single file or not. Some prefer to write as many code as they can in one single line. I doubt that they do it to ease maintenance and to avoid feature creep.
[1]: https://github.com/bottlepy/bottle/issues/1158#issuecomment-... [2]: https://github.com/bottlepy/bottle/blob/master/bottle.py [3]: https://github.com/bottlepy/bottle/blob/332215b2b1b3de5a321b...