@ignaloidas@algernon Zen of Python is self-contradictory, you can prove anything you want from it
I think it's ok to prefer an explicit addition like you suggest. But I don't prefer it, and I think it's also valid to not prefer it. Therefore, I still think "you shouldn't want monads" is false.
The fact that it is collected into a common object is a very important part of the process, but with MonadWriter, for some functions that might only be visible in the function signature - and honestly, to me, function signatures are a minor part of the program. In contemporary Haskell, obviously they aren't, but that's why I don't like contemporary Haskell.
"Explicit is better than implicit" says Zen of Python, and I agree - I'd rather see an explicit addition to the total metrics, rather than an implicit one.
Returning a MetricsSet from functions would require knowing the implementation of MetricsSet inside each of those functions. Merging it after every call without a programmable semicolon would be cumbersome. I guess I could override some operator like += or |= to make it more conscise... and I guess that would look fairly readable...
but that's what a MonadWriter would do under the hood, except without all the boilerplate, and in a way where the caller determines the impl
@wolf480pl@mstdn.io@algernon@trunk.mad-scientist.club Returning a MetricsSet from functions would require knowing the implementation of MetricsSet inside each of those functions.I'm not sure I understand the problem here? I guess you lose the loose typing through protocols, but I don't find that a major problem here - your MetricsSet could join based on a protocol, building a tree of whatever implementations fit the specific function's output best. Though I don't think there's real value in that.
I don't know why do you think merging would need to be cumbersome - it's a two argument function call, with one of those being implicit, and if you want, there are fitting operations to overload.
As for caller determining the implementation - make your MetricsSet protocol loose enough and you can export in whatever format you want - you'd really only need to change the top layer for that.
> I personally value knowing what exactly from current scope is passed into the function I'm calling
With monads, that's explicitly specified in the type of the function. For me that's enough, and passing it explicitly the way I'm doing in Python feels like boilerplate.
@wolf480pl@mstdn.io@algernon@trunk.mad-scientist.club tbh I prefer passing such an object explicitly instead of it being implicitly carried - I personally value knowing what exactly from current scope is passed into the function I'm calling. Overall, I think that code is fine.
Though honestly you also could've avoided this by going in reverse - returning MetricsSet's from functions that you merge and tag - and it would've avoided mutable objects and bug potential from using them (e.g. in line 192 you are taking the exporter from previous operation and getting a new one with updated labels - which might end up not quite how you want after modifying code). Which I'd say is a more functional solution actually, and with less potential for error
I was writing a script that converts ss(8) output to prometheus metrics. I ended up writing a class that `emit` method, and manually passing it as 1st argument throughout all the parser functions like a savage.
@wolf480pl@mstdn.io@algernon@trunk.mad-scientist.club I don't see why you'd need anything like that in python? Honestly you usually just have some non-local variable and work through that - and if that doesn't suffice, I'd honestly call that a code smell
My perception is that I'm saying I find coding in Python less enjoyable because of lack of monads, and you're saying that if I was using Python differently, I woulf enjoy it more.
Then we arrive at a point where you're saying you prefer more explicit which is why you enjoy a particular pythonic way of writing code.
To which I say I don't enjoy that, I prefer more implicit.
I'd say it's "un-Pythonic" to not go though explicit addition. In other languages - sure, maybe, but I think such languages over-use monads to the detriment of code readability.