6 ms·

Not even, I believe objects in python are just maps with some syntax sugar. I’m not sure what this is buying over a static class aside from being slower and mor

by phyrex 3y ago

Not even, I believe objects in python are just maps with some syntax sugar. I’m not sure what this is buying over a static class aside from being slower and more awkward to use?

DarkNova6 3y ago
Documentation, type hints and arguably readability. But I understand that this is a very python answer.
Pxtl 3y ago
In the article he describes using this for user-provided mathematical expressions. I suppose that makes sense if you're implementing a light DSL in python... But maybe don't? Edit: I don't believe this is any slower, actually. It may even be marginally faster than a class, since a class adds some QOL features that will add a little overhead that would add a few branches to the code path. But if you're worried about speed, don't use Python anyways.
raverbashing 3y ago
> I’m not sure what this is buying over a static class 1. It is not static. It can be configured, changed at runtime, etc 2. First order functions are very powerful as well
- fluidcruft 3y ago
  Modifiability is also true of python objects and classes. This is basically reinventing obj.__dict__ The real difference is that since it's not an object, "self" isn't in the function signature which to be fair can be annoying for a collection of stateless functions. So this is actually closer to a module.
  - sanderjd 3y ago
    Yeah, you alluded to this at the end, but you don't need to define these as methods on an instance (requiring `self`) if they don't require state.
    - fluidcruft 3y ago
      To be fair, I have come prefer approaching the problem stated in the link in the exact opposite direction. Specifically the part about having a collection of functions with signatures that are similar/identical. The example in the post is of a simple signature, but if you have more complex (and long) signatures and a bunch of functions that use them, it might be worth thinking about replacing the argument list with a frozen dataclass. @dataclass(frozen=True) class MyArguments: a: int, b: str, c: list = None def func1(self): ... def func2(self): ... etc. You can also sprinkle in @property and functools things like @cached, @cached_property when desired. It also lets you create functions that transform MyArguments into different MyArguments.
      - sanderjd 3y ago
        Yeah I'm with you here too.
        fluidcruft 3y ago
        The struggle to figure out what the hell to name MyArguments is real. But that's also true about picking a name for the dict-of-functions-that-have-a-similar-weird-signature. :D
- sanderjd 3y ago
  (1) seems like a bug rather than a feature, to me, outside extremely narrow use cases. It's generally much better to be able to statically reason about what code exists and how it is structured and called, than to have to reason about runtime behavior to determine those things. I agree with (2), but I'm not sure the pattern from the OP is a good example of using that power. It seems like using a language feature - mapping a string to an anonymous function - when a better one exists: defining named functions. Named functions can be looked up dynamically by name in python, and are (I think) generally more clear to a reader, especially with the standard documentation and type hints.
  - raverbashing 3y ago
    1) is absolutely not a bug, though sure you don't want to overuse it" "Oh but you can replace this with a derived class", it's not as flexible (for example, mix and matching, etc) > than to have to reason about runtime behavior to determine those things. Sure if you only do CRUD you probably won't run into those cases. Math heavy, scientific code, simulations, etc might disagree
    - sanderjd 3y ago
      > "Oh but you can replace this with a derived class", it's not as flexible (for example, mix and matching, etc) What do you mean by "mix and matching"? I feel like a concrete example might help me understand what you're thinking of in this thread. > Sure if you only do CRUD you probably won't run into those cases. Math heavy, scientific code, simulations, etc might disagree Ha, it's funny because I've recently started doing more math-y / scientific / simulation work in python, after a career spent mostly doing CRUD-y things in not-python, and I've never been more convinced that it is best to make code as statically legible as possible. It's hard enough to make sure the math and the algorithms are right, I don't want to also be reasoning through dynamic abstractions. But again, maybe there's a concrete thing you're thinking of here that I'm not seeing!
      - raverbashing 3y ago
        > What do you mean by "mix and matching"? A bit of a contrived example, but think of multiple inheritance but dynamically. > maybe there's a concrete thing you're thinking of here Genetic programming would be the main use case of this (of table dispatch, not the "mix and match thing", which ok, is a bit of a corner case > I've never been more convinced that it is best to make code as statically legible as possible Given how the average academic code is, I don't think I can disagree with you much And I think it's also a question of syntax. For those kinds of things a lambda might be more readable, but a typed lambda is still a lambda.
bjourne 3y ago
It's open so you can change the dispatch during runtime. It's also pretty nice to dispatch on strings as not all situations require complicated setup with class hierarchies, enumeration classes, or what have you.

by phyrex 3y ago

Not even, I believe objects in python are just maps with some syntax sugar. I’m not sure what this is buying over a static class aside from being slower and more awkward to use?

DarkNova6 3y ago

Documentation, type hints and arguably readability. But I understand that this is a very python answer.

Pxtl 3y ago

In the article he describes using this for user-provided mathematical expressions. I suppose that makes sense if you're implementing a light DSL in python... But maybe don't? Edit: I don't believe this is any slower, actually. It may even be marginally faster than a class, since a class adds some QOL features that will add a little overhead that would add a few branches to the code path. But if you're worried about speed, don't use Python anyways.

raverbashing 3y ago

> I’m not sure what this is buying over a static class 1. It is not static. It can be configured, changed at runtime, etc 2. First order functions are very powerful as well

fluidcruft 3y ago
Modifiability is also true of python objects and classes. This is basically reinventing obj.__dict__ The real difference is that since it's not an object, "self" isn't in the function signature which to be fair can be annoying for a collection of stateless functions. So this is actually closer to a module.
- sanderjd 3y ago
  Yeah, you alluded to this at the end, but you don't need to define these as methods on an instance (requiring `self`) if they don't require state.
  - fluidcruft 3y ago
    To be fair, I have come prefer approaching the problem stated in the link in the exact opposite direction. Specifically the part about having a collection of functions with signatures that are similar/identical. The example in the post is of a simple signature, but if you have more complex (and long) signatures and a bunch of functions that use them, it might be worth thinking about replacing the argument list with a frozen dataclass. @dataclass(frozen=True) class MyArguments: a: int, b: str, c: list = None def func1(self): ... def func2(self): ... etc. You can also sprinkle in @property and functools things like @cached, @cached_property when desired. It also lets you create functions that transform MyArguments into different MyArguments.
    - sanderjd 3y ago
      Yeah I'm with you here too.
      - fluidcruft 3y ago
        The struggle to figure out what the hell to name MyArguments is real. But that's also true about picking a name for the dict-of-functions-that-have-a-similar-weird-signature. :D
sanderjd 3y ago
(1) seems like a bug rather than a feature, to me, outside extremely narrow use cases. It's generally much better to be able to statically reason about what code exists and how it is structured and called, than to have to reason about runtime behavior to determine those things. I agree with (2), but I'm not sure the pattern from the OP is a good example of using that power. It seems like using a language feature - mapping a string to an anonymous function - when a better one exists: defining named functions. Named functions can be looked up dynamically by name in python, and are (I think) generally more clear to a reader, especially with the standard documentation and type hints.
- raverbashing 3y ago
  1) is absolutely not a bug, though sure you don't want to overuse it" "Oh but you can replace this with a derived class", it's not as flexible (for example, mix and matching, etc) > than to have to reason about runtime behavior to determine those things. Sure if you only do CRUD you probably won't run into those cases. Math heavy, scientific code, simulations, etc might disagree
  - sanderjd 3y ago
    > "Oh but you can replace this with a derived class", it's not as flexible (for example, mix and matching, etc) What do you mean by "mix and matching"? I feel like a concrete example might help me understand what you're thinking of in this thread. > Sure if you only do CRUD you probably won't run into those cases. Math heavy, scientific code, simulations, etc might disagree Ha, it's funny because I've recently started doing more math-y / scientific / simulation work in python, after a career spent mostly doing CRUD-y things in not-python, and I've never been more convinced that it is best to make code as statically legible as possible. It's hard enough to make sure the math and the algorithms are right, I don't want to also be reasoning through dynamic abstractions. But again, maybe there's a concrete thing you're thinking of here that I'm not seeing!
    - raverbashing 3y ago
      > What do you mean by "mix and matching"? A bit of a contrived example, but think of multiple inheritance but dynamically. > maybe there's a concrete thing you're thinking of here Genetic programming would be the main use case of this (of table dispatch, not the "mix and match thing", which ok, is a bit of a corner case > I've never been more convinced that it is best to make code as statically legible as possible Given how the average academic code is, I don't think I can disagree with you much And I think it's also a question of syntax. For those kinds of things a lambda might be more readable, but a typed lambda is still a lambda.

bjourne 3y ago

It's open so you can change the dispatch during runtime. It's also pretty nice to dispatch on strings as not all situations require complicated setup with class hierarchies, enumeration classes, or what have you.