Library, executable seperation

[ItsShadowCone]

It's nice how you put your code in a seperate libwyog.py, but consequently, libwyog.py should only "export" (aka define) functions for like init, add, commit, etc and the wyog executable should do command line parsing etc.

[Thibault Polge]

Thanks for the suggestion, but I'm afraid implementing this change would make the tutorial harder to follow with no real gain. The point of having two different files is to make sure that the program is runnable at any point of the tutorial without expecting the user to insert new code at any other place than the bottom of the main file. Since Python is a dynamic language, everything must have been evaluated before the main function runs. The only simple solution to insure a clear separation of concerns would be to add a third file libwyagcliargs.py or something, but I'm not really convinced the gain is worth the increase in complexity.

[ItsShadowCone]

Suggestion persists, I have the feeling you don't quite understand why one splits code into a library file and an executable, because *adding code at the bottom so it's less complex" isn't the point. I would think it wouldn't add too much in complexity but after all it's your tutorial.

[Thibault Polge]

On 25 Mar 2019, at 07:27, Cl1608Ho ***@***.***> wrote: I have the feeling you don't quite understand why one splits code into a library file and an executable, because *adding code at the bottom so it's less complex" isn't the point.

I'm afraid you didn't understand my previous reply. Simplicity is not a general, abstract, in-a-perfect-world motivation for separating library and executable, it is the rationale for splitting code *in the very context of this tutorial*. To be extremely clear, I'd rather have stayed to a single-file approach but I'm afraid it would have made the tutorial *harder* to follow. I agree with you that from a code quality perspective, what I do is *not* good design; but I don't plan on changing it if the change introduces more complexity from the reader's perspective than the present state. That is to say, I'd be happy to implement any change that would improvise the overall design quality without sacrificing clarity. But clarity, not design quality, is the primary concern here. If I find the time, I may add an appendix to the document to explain why wyag is structured the way it is. [Note to self: things to explain: the big-elif-switch-why-not-a-dict thing, the classes-as-structs thing and the argument-processing-logic-in-library thing] Ps: I'm sending this from my phone, I hope it will render correctly on github. Apologies if it doesn't