Because, in the latter case, you have to declare a function argument for /every possible option/ that you want your graphics API to expose, and you need to do this every time you add a new option.
On the other hand, declaring the options through composition means that the API for "plot" remains static, and adding/removing options can be done trivially without an API change.
Composition (rather than parameters) is also more flexible. Let's say you want to divide your plot into three sub-plots, two of which are 200x200, and another which is 200x400. How do you express this as a keyword parameter? In composition, you could do something like:
Isn't this somewhat the point of python's override capability? You can exactly define what addition means here, just like you have to define what addition means for a matrix or another data structure.
Separately you might find this to be smelly design, but then you should remember that this at least has precedence ¯\_(ツ)_/¯
Honestly operator overloading is almost always a bad choice IMO. There are cases (e.g. matrix math) where it's the right choice because of semantic clarity, but the indirection it creates in exchange for readability is costly. It's always obvious when a function is being called, and how to navigate to the implementation, but the same is not true of overloaded operators.
Well, it's like most tools. For this particular use, does it give more than it takes? If so, use it.
Matrix multiplication? Yeah, everybody knows there's a function being called. And, if it was implemented right, the users almost never have to look at the implementation.
Many other possible uses? Nope. Just nope. Not worth it.
Because, in the latter case, you have to declare a function argument for /every possible option/ that you want your graphics API to expose, and you need to do this every time you add a new option.
On the other hand, declaring the options through composition means that the API for "plot" remains static, and adding/removing options can be done trivially without an API change.
Composition (rather than parameters) is also more flexible. Let's say you want to divide your plot into three sub-plots, two of which are 200x200, and another which is 200x400. How do you express this as a keyword parameter? In composition, you could do something like:
plot( ggsubplot(ggvsplit(ggsize(200,400), gghsplit(ggsize(200,200), ggsize(200,200)))) )
And how do you express that as arithmetic?
I can get as far as `plot() / 3` but then no idea how to proceed. I don't think overloading arithmetic is a very good way to express this.
Isn't this somewhat the point of python's override capability? You can exactly define what addition means here, just like you have to define what addition means for a matrix or another data structure.
Separately you might find this to be smelly design, but then you should remember that this at least has precedence ¯\_(ツ)_/¯
Honestly operator overloading is almost always a bad choice IMO. There are cases (e.g. matrix math) where it's the right choice because of semantic clarity, but the indirection it creates in exchange for readability is costly. It's always obvious when a function is being called, and how to navigate to the implementation, but the same is not true of overloaded operators.
Well, it's like most tools. For this particular use, does it give more than it takes? If so, use it.
Matrix multiplication? Yeah, everybody knows there's a function being called. And, if it was implemented right, the users almost never have to look at the implementation.
Many other possible uses? Nope. Just nope. Not worth it.
kwargs exists, and is rather more pythonic. Just pass the kwargs dict to a standard formatting function, et voila.
Sadly, this drive towards the API design that matplotlib resembles, the raison d'etre of this library is the unusual (imho, great) API