> 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 <[email protected] > <mailto:[email protected]>> 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 > > <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? >
_______________________________________________ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/OXVPLG7SLP2ZYVOWYUNGJ7DBUFA53GX5/ Code of Conduct: http://python.org/psf/codeofconduct/
