PEP draft: Unifying function/method classes
I have prepared a PEP draft for unifying function/method classes. You can find it at https://github.com/jdemeyer/PEP-functions This has not officially been submitted as PEP yet, I want to hear your comments first. Thanks, Jeroen.
On Sat, Mar 31, 2018 at 04:48:56PM +0200, Jeroen Demeyer wrote:
It seems like a huge amount of work compared to the motivation: allow functions written in C to support introspection. Quote: "In particular, it is currently not possible to implement a function efficiently in C (only built-in functions can do that) while still allowing introspection like inspect.getfullargspec or inspect.getsourcefile (only Python functions can do that)." Why isn't the answer to provide a hook to support introspection? In the Subclassing section, you say: "We disallow subclassing of builtin_function and method to allow fast isinstance checks for those types." Seems to me that if you want a fast, exact (no subclasses) check, you should use "type(obj) is Class" rather than isinstance. If the *only* reason to prohibit subclassing is to make isinstance a bit faster, I don't think that's a good enough reason. -- Steve
On 3/31/2018 12:09 PM, Steven D'Aprano wrote:
inspect.signature, which superceded .getfullargspec, works with C-coded functions that use ArgumentClinic.
I would be all for more of the builtins and stdlib being converted. Can't 3rd-party C code use ArgumentClinic?
inspect.getsourcefile (only Python functions can do that)."
Sourcefile is meaningless when there is no source file. C sources would be far less useful than Python sources. -- Terry Jan Reedy
Thanks for writing such hard PEP. At first glance, it new type hierarchy seems OK. But I can't understand rational for new flags. And it's very difficult to estimate runtime and maintenance cost of the PEP, without draft implementation. FASTCALL is introduced in recently version, and it make implementation complicated. I'm afraid that this PEP make it worse. For making FASTCALL stable & public, I'm +1 if Victor and Serhiy agree. Regards,
31.03.18 17:48, Jeroen Demeyer пише:
I once tried to move in this direction (unifying the set of attributes for functions). But there are more than two kinds of function-like objects, so I deferred this work until I have more time. Do you have working implementation? How much code should be modified for passing all tests? Ideally only specific code in the inspect module and like should be modified.
I want to support this work. I can't promise your PEP will be accepted, but it looks like you've done your homework, and you're getting feedback from core devs who care about this area. (One of them may end up BDFL-delegate.) It will be a long road to success, but I recommend that you start with a PR to the peps repo. Merging new versions there will be easy (the requirements for accepting edits to new PEPs in that repo are really low -- it just needs to successfully generate HTML). Once your PEP is there you should probably focus on an implementation. On Sat, Mar 31, 2018 at 7:48 AM, Jeroen Demeyer <J.Demeyer@ugent.be> wrote:
-- --Guido van Rossum (python.org/~guido)
On 1 April 2018 at 00:48, Jeroen Demeyer <J.Demeyer@ugent.be> wrote:
I've only read the description of the proposed type heirarchy so far, but I really like where you're heading with this. A couple of specific naming suggestions: * method -> bound_method "method" is an overloaded term, and this will make it clearer that these objects are specifically for bound methods. * generic_function -> defined_function "Generic function" already refers to functions decorated with functools.singledispatch (as well as the general concept of generic functions), so re-using it for a different purpose here would be confusing. I don't have a particularly great alternative name to suggest, but "defined_function" at least takes its inspiration from the "def" keyword, and the fact that these functions are significantly better defined than builtin ones (from a runtime introspection perspective). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Sat, Mar 31, 2018 at 04:48:56PM +0200, Jeroen Demeyer wrote:
It seems like a huge amount of work compared to the motivation: allow functions written in C to support introspection. Quote: "In particular, it is currently not possible to implement a function efficiently in C (only built-in functions can do that) while still allowing introspection like inspect.getfullargspec or inspect.getsourcefile (only Python functions can do that)." Why isn't the answer to provide a hook to support introspection? In the Subclassing section, you say: "We disallow subclassing of builtin_function and method to allow fast isinstance checks for those types." Seems to me that if you want a fast, exact (no subclasses) check, you should use "type(obj) is Class" rather than isinstance. If the *only* reason to prohibit subclassing is to make isinstance a bit faster, I don't think that's a good enough reason. -- Steve
On 3/31/2018 12:09 PM, Steven D'Aprano wrote:
inspect.signature, which superceded .getfullargspec, works with C-coded functions that use ArgumentClinic.
I would be all for more of the builtins and stdlib being converted. Can't 3rd-party C code use ArgumentClinic?
inspect.getsourcefile (only Python functions can do that)."
Sourcefile is meaningless when there is no source file. C sources would be far less useful than Python sources. -- Terry Jan Reedy
Thanks for writing such hard PEP. At first glance, it new type hierarchy seems OK. But I can't understand rational for new flags. And it's very difficult to estimate runtime and maintenance cost of the PEP, without draft implementation. FASTCALL is introduced in recently version, and it make implementation complicated. I'm afraid that this PEP make it worse. For making FASTCALL stable & public, I'm +1 if Victor and Serhiy agree. Regards,
31.03.18 17:48, Jeroen Demeyer пише:
I once tried to move in this direction (unifying the set of attributes for functions). But there are more than two kinds of function-like objects, so I deferred this work until I have more time. Do you have working implementation? How much code should be modified for passing all tests? Ideally only specific code in the inspect module and like should be modified.
I want to support this work. I can't promise your PEP will be accepted, but it looks like you've done your homework, and you're getting feedback from core devs who care about this area. (One of them may end up BDFL-delegate.) It will be a long road to success, but I recommend that you start with a PR to the peps repo. Merging new versions there will be easy (the requirements for accepting edits to new PEPs in that repo are really low -- it just needs to successfully generate HTML). Once your PEP is there you should probably focus on an implementation. On Sat, Mar 31, 2018 at 7:48 AM, Jeroen Demeyer <J.Demeyer@ugent.be> wrote:
-- --Guido van Rossum (python.org/~guido)
On 1 April 2018 at 00:48, Jeroen Demeyer <J.Demeyer@ugent.be> wrote:
I've only read the description of the proposed type heirarchy so far, but I really like where you're heading with this. A couple of specific naming suggestions: * method -> bound_method "method" is an overloaded term, and this will make it clearer that these objects are specifically for bound methods. * generic_function -> defined_function "Generic function" already refers to functions decorated with functools.singledispatch (as well as the general concept of generic functions), so re-using it for a different purpose here would be confusing. I don't have a particularly great alternative name to suggest, but "defined_function" at least takes its inspiration from the "def" keyword, and the fact that these functions are significantly better defined than builtin ones (from a runtime introspection perspective). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (7)
-
Guido van Rossum -
INADA Naoki -
Jeroen Demeyer -
Nick Coghlan -
Serhiy Storchaka -
Steven D'Aprano -
Terry Reedy