Re: [Python-Dev] PEP 575: Unifying function/method classes
On 2018-04-13 21:30, Raymond Hettinger wrote:
It would be nice to have a section that specifically discusses the implications with respect to other existing function-like tooling: classmethod, staticmethod, partial, itemgetter, attrgetter, methodgetter, etc.
My hope is that there are no such implications. An important design goal of this PEP (which I believe I achieved) is that as long as you're doing duck typing, you should be safe. I believe that the tools in your list do exactly that. It's only when you use inspect or when you do type checks that you will see the difference with this PEP. After implementing the C code part of my PEP, there were only a relatively small number of test failures. You can look at this commit which contains all Python code changes of my implementation, it doesn't look so bad: https://github.com/jdemeyer/cpython/commit/c404a8f1b7d9525dd2842712fe183a051...
For example, I would need to update the code in random._randbelow().
For the record, there are no test failures related to this, but maybe that's just because tests for this are missing.
On Sat, Apr 14, 2018 at 2:17 AM, Jeroen Demeyer <J.Demeyer@ugent.be> wrote:
On 2018-04-13 21:30, Raymond Hettinger wrote:
It would be nice to have a section that specifically discusses the implications with respect to other existing function-like tooling: classmethod, staticmethod, partial, itemgetter, attrgetter, methodgetter, etc.
My hope is that there are no such implications. An important design goal of this PEP (which I believe I achieved) is that as long as you're doing duck typing, you should be safe. I believe that the tools in your list do exactly that.
It's only when you use inspect or when you do type checks that you will see the difference with this PEP.
That actually sounds like a pretty big problem. I'm sure there is lots of code that doesn't *just* duck-type nor calls inspect but uses isinstance() to decide how to extract the desired information.
After implementing the C code part of my PEP, there were only a relatively small number of test failures. You can look at this commit which contains all Python code changes of my implementation, it doesn't look so bad:
https://github.com/jdemeyer/cpython/commit/c404a8f1b7d9525dd 2842712fe183a051a4b5094
For example, I would need to update the code in random._randbelow().
For the record, there are no test failures related to this, but maybe that's just because tests for this are missing.
-- --Guido van Rossum (python.org/~guido)
Hi, let me start by saying that I'm much in favour of this change. It cleans up a lot of the function implementation and makes it much easier to integrate efficiently with external wrapper tools. Guido van Rossum schrieb am 14.04.2018 um 23:14:
On Sat, Apr 14, 2018 at 2:17 AM, Jeroen Demeyer wrote:
On 2018-04-13 21:30, Raymond Hettinger wrote:
It would be nice to have a section that specifically discusses the implications with respect to other existing function-like tooling: classmethod, staticmethod, partial, itemgetter, attrgetter, methodgetter, etc.
My hope is that there are no such implications. An important design goal of this PEP (which I believe I achieved) is that as long as you're doing duck typing, you should be safe. I believe that the tools in your list do exactly that.
It's only when you use inspect or when you do type checks that you will see the difference with this PEP.
That actually sounds like a pretty big problem. I'm sure there is lots of code that doesn't *just* duck-type nor calls inspect but uses isinstance() to decide how to extract the desired information.
After some discussion, it seems that we can avoid the backwards incompatibility by going half of the way first. We can keep the existing "builtin_function_or_method" type for now, and mostly just add the common base function type at the top. That provides most of the benefits, including fast integration with native external function implementations and most of the cleanup, while not requiring changes to type tests in user code. The final split could then be done later, e.g. for Py4.0, where people would be less surprised about minor breakages. The problem is that this change does not really fit into the deprecation cycle since there is no specific use case to warn about. Most code will simply keep working, and there is no specific code pattern that would break. It really depends on the exact reasons why some piece of code (thinks it) needs to do a type check. Such code is usually easy to fix, and also improve along the way, probably even by reducing the type checking or by starting to use "inspect" instead of direct (fragile) type checks. Much of the code that could potentially break probably only exists to work around the quirks of the current function types implementation in CPython, which this PEP specifically aims to clean up. Stefan
2018-05-03 11:22 GMT+02:00 Stefan Behnel <stefan_ml@behnel.de>:
The final split could then be done later, e.g. for Py4.0, where people would be less surprised about minor breakages.
Please don't queue backward incompatible changes for Python 4.0. You should use the regular deprecation process. (I didn't read the full thread, sorry :-p) Victor
participants (4)
-
Guido van Rossum -
Jeroen Demeyer -
Stefan Behnel -
Victor Stinner