Add explicit method overloading to STL
Don't know if this is already a PEP, but I'd love to see something like this <https://www.codementor.io/@arpitbhayani/overload-functions-in-python-13e32ah...> in Python— a decorator @overload that creates multiple copies of functions/methods based on their arguments' types. (This is much narrower in scope than PEP 3124, before anyone asks.)
On Mon, Aug 23, 2021 at 09:10:49PM -0500, Will Bradley wrote:
Do you mean something like functools.singledispatch? https://docs.python.org/3/library/functools.html#functools.singledispatch If not, how are they different? -- Steve
On 8/23/21 10:21 PM, Steven D'Aprano wrote:
You may also be interested in a package I wrote for doing this kind of thing: https://pypi.org/project/signature-dispatch/ The differences between `functools.singledispatch`, the linked article, and my package are: * `functools.singledispatch` considers only the type of the first argument. * The linked article only considers the number of positional arguments. * My package considers the entire signature, including type annotations. -Kale
You may also be interested in a package I wrote for doing this kind of thing:
After reading about this project, I'm interested in the idea of callable modules in Python. However, that's another issue for another day and another person. On Wed, Aug 25, 2021, 6:46 PM Finn Mason <finnjavier08@gmail.com> wrote:
I'd like to know how your idea is different from PEP 3124. Could you please explain?
TBH I hadn't heard of PEP 3124 until this thread, so hopefully I'm not getting something wrong. But my understanding is that the `@overload` decorator from PEP 3124 (i) requires all of the functions it decorates to have the same number of arguments (i.e. only the type annotations can differ) and (ii) doesn't support variable/keyword arguments. These both seem like huge limitations to me. I'd definitely expect tools in the stdlib to be more general than that. It's also not clear to me if `@overload` will support generic type annotations like `List[str]`. Checking this kind of type annotation isn't trivial, and there's currently nothing in the standard library that can do it. So unless PEP 3124 is proposing to add such a type-checking function (which I think would be a great thing), this is probably another big limitation.
After reading about this project, I'm interested in the idea of callable modules in Python. However, that's another issue for another day and another person.
I really like using callable modules for libraries that are basically a single function. It's much easier to do now than it used to be, too. Still, it'd be nice if you could just do `def __call__(): ...` and have it work. I think this idea has come up before, though, and I have no idea what the technical considerations are. -Kale On 8/25/21 8:53 PM, Finn Mason wrote:
On Mon, Aug 23, 2021 at 09:10:49PM -0500, Will Bradley wrote:
Do you mean something like functools.singledispatch? https://docs.python.org/3/library/functools.html#functools.singledispatch If not, how are they different? -- Steve
On 8/23/21 10:21 PM, Steven D'Aprano wrote:
You may also be interested in a package I wrote for doing this kind of thing: https://pypi.org/project/signature-dispatch/ The differences between `functools.singledispatch`, the linked article, and my package are: * `functools.singledispatch` considers only the type of the first argument. * The linked article only considers the number of positional arguments. * My package considers the entire signature, including type annotations. -Kale
You may also be interested in a package I wrote for doing this kind of thing:
After reading about this project, I'm interested in the idea of callable modules in Python. However, that's another issue for another day and another person. On Wed, Aug 25, 2021, 6:46 PM Finn Mason <finnjavier08@gmail.com> wrote:
I'd like to know how your idea is different from PEP 3124. Could you please explain?
TBH I hadn't heard of PEP 3124 until this thread, so hopefully I'm not getting something wrong. But my understanding is that the `@overload` decorator from PEP 3124 (i) requires all of the functions it decorates to have the same number of arguments (i.e. only the type annotations can differ) and (ii) doesn't support variable/keyword arguments. These both seem like huge limitations to me. I'd definitely expect tools in the stdlib to be more general than that. It's also not clear to me if `@overload` will support generic type annotations like `List[str]`. Checking this kind of type annotation isn't trivial, and there's currently nothing in the standard library that can do it. So unless PEP 3124 is proposing to add such a type-checking function (which I think would be a great thing), this is probably another big limitation.
After reading about this project, I'm interested in the idea of callable modules in Python. However, that's another issue for another day and another person.
I really like using callable modules for libraries that are basically a single function. It's much easier to do now than it used to be, too. Still, it'd be nice if you could just do `def __call__(): ...` and have it work. I think this idea has come up before, though, and I have no idea what the technical considerations are. -Kale On 8/25/21 8:53 PM, Finn Mason wrote:
participants (5)
-
Finn Mason -
Kale Kundert -
Serhiy Storchaka -
Steven D'Aprano -
Will Bradley