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-13e32ahzqt> 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:
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-13e32ahzqt> 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.)
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:
On Mon, Aug 23, 2021 at 09:10:49PM -0500, Will Bradley wrote:
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-13e32ahzqt> 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.) Do you mean something like functools.singledispatch?
https://docs.python.org/3/library/functools.html#functools.singledispatch
If not, how are they different?
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
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.) Do you mean something like functools.singledispatch?
It seems there are already tools for overloading. In terms of type hints, there's @typing.overload. From what I can tell, overloading the implementation is generally frowned upon in Python. I'd like to know how your idea is different from PEP 3124. Could you please explain?
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:
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.) Do you mean something like functools.singledispatch?
It seems there are already tools for overloading. In terms of type hints, there's @typing.overload. From what I can tell, overloading the implementation is generally frowned upon in Python. I'd like to know how your idea is different from PEP 3124. Could you please explain?
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:
You may also be interested in a package I wrote for doing this kind of thing:
https://pypi.org/project/signature-dispatch/ <https://pypi.org/project/signature-dispatch/>
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 <mailto:finnjavier08@gmail.com>> wrote:
>> 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... <https://www.codementor.io/@arpitbhayani/overload-functions-in-python-13e32ahzqt>> >> 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.) > Do you mean something like functools.singledispatch?
It seems there are already tools for overloading. In terms of type hints, there's @typing.overload. From what I can tell, overloading the implementation is generally frowned upon in Python. I'd like to know how your idea is different from PEP 3124. Could you please explain?
24.08.21 05:10, Will Bradley пише:
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-13e32ahzqt> 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.)
What is STL here?
participants (5)
-
Finn Mason -
Kale Kundert -
Serhiy Storchaka -
Steven D'Aprano -
Will Bradley