3 ms·

So the first example can be done like so: def do_thing(context): def step1(): pass def step2(): pass def st

So the first example can be done like so: def do_thing(context): def step1(): pass def step2(): pass def step3(): pass step1() step2() step3() The second example can be replaced with: def make_thing_doer(db_name): def f(context): pass return f I think both examples are clearer and involve less boilerplate. But I specifically asked why that initial example posted to the blog was written the way it was. I will stress that "because in the future you may want to do X or Y with it" is not a really good reason because there is absolutely no reason why you couldn't just replace the function when it came to that point. Moreover, the database example you gave would require changing the code just as much as the function example I gave. specifically, in your case: tasks = [ ThingDoer1(), ThingDoer2(db_name), ThingDoer3(), ] or in my case: tasks = [ do_something_1, make_thing_doer_2(db_name), do_something_3, ] Once again, less code, fewer noisy parentheses, I don't see the advantage. Edit: I missed the inheritance example at first read but this can trivially be implemented like so: def make_thing_doer(custom_step): def step1(): pass def step3(): pass def f(context): step1() custom_step(context) step2() return f or more simply: def do_thing(custom_step, context): ... step1() custom_step(context) step3() def special_step(context): pass do_special_thing = lambda c: do_thing(special_step, c) That doesn't implicitly inherit all the state. In which case I would concede that a class may be worthwhile. But as I already said, making the code so ugly initially is not justified by the possibility of eventually needing it to do this specific thing. You can still make the code do this specific thing without ever needing to make it so ugly to begin with. Nothing stops you from mixing the style and implementing __call__ in the class (or subclassing from a class which implements __call__ and calls run() if you don't like double underscores.

Jtsummers 5y ago
I mean, if you don’t like classes then don’t use classes. It’s not forced here. But if the author’s article is correct, they’re planning to change the script. Presumably they’ve done it enough to know a basic structure that’s worked well for them once they’ve started making changes. Why not set up that structure at the start if you know it’ll be the end result?
- Arch-TK 5y ago
  > Why not set up that structure at the start if you know it’ll be the end result? Precisely because it's an unnecessary amount of code overhead. There's no indication at all that IF he needed to expand the code that classes would be necessary UNTIL there were very specific requirements and there's also no reason why he should put that code in place in case of that requirement popping up. It's always cheaper to write the simplest code you need at the time and then delete it (or rework some of it) and write the more complicated code you need in the future than it is to write more complicated code up front and expand less on some of it in the future. If the point of the article is effectively "minimising the activation energy required to start automating a task" then surely the code should also be minimal?
  - Jtsummers 5y ago
    > Precisely because it's an unnecessary amount of code overhead. One extra line per step is not a lot of overhead.
    - Arch-TK 5y ago
      It's more than one line though is it, it's a lot more _text_ even ignoring whitespace it's almost twice as much text. And that's the least important metric! Classes carry a lot more baggage. In the sense that if you see one, your expectations change and expand. The realm of possibilities expands too. This puts extra mental load when anyone new to the codebase has to look at it. The fact that I looked at that code and spent 5 minutes trying to figure out why you would want classes there and what exactly it achieves is precisely what you want to avoid in codebases. I audit code for a living, a lot of it, it takes far more work to audit code where the authors put a lot of unnecessary boilerplate or unnecessarily flexible code in place because it means I have to start figuring out what the authors intentions were. The expanded realm of possibilities means I have to check for more behaviors. It slows down the reading process.

Jtsummers 5y ago

I mean, if you don’t like classes then don’t use classes. It’s not forced here. But if the author’s article is correct, they’re planning to change the script. Presumably they’ve done it enough to know a basic structure that’s worked well for them once they’ve started making changes. Why not set up that structure at the start if you know it’ll be the end result?

Arch-TK 5y ago
> Why not set up that structure at the start if you know it’ll be the end result? Precisely because it's an unnecessary amount of code overhead. There's no indication at all that IF he needed to expand the code that classes would be necessary UNTIL there were very specific requirements and there's also no reason why he should put that code in place in case of that requirement popping up. It's always cheaper to write the simplest code you need at the time and then delete it (or rework some of it) and write the more complicated code you need in the future than it is to write more complicated code up front and expand less on some of it in the future. If the point of the article is effectively "minimising the activation energy required to start automating a task" then surely the code should also be minimal?
- Jtsummers 5y ago
  > Precisely because it's an unnecessary amount of code overhead. One extra line per step is not a lot of overhead.
  - Arch-TK 5y ago
    It's more than one line though is it, it's a lot more _text_ even ignoring whitespace it's almost twice as much text. And that's the least important metric! Classes carry a lot more baggage. In the sense that if you see one, your expectations change and expand. The realm of possibilities expands too. This puts extra mental load when anyone new to the codebase has to look at it. The fact that I looked at that code and spent 5 minutes trying to figure out why you would want classes there and what exactly it achieves is precisely what you want to avoid in codebases. I audit code for a living, a lot of it, it takes far more work to audit code where the authors put a lot of unnecessary boilerplate or unnecessarily flexible code in place because it means I have to start figuring out what the authors intentions were. The expanded realm of possibilities means I have to check for more behaviors. It slows down the reading process.