Rejecting PEP 637 (Support for indexing with keyword arguments)
Hi Stefano, Thank you for submitting PEP 637 (Support for indexing with keyword arguments). The Steering Council has reviewed the PEP and after careful consideration, we have decided to reject the PEP. There are a number of reasons for this, but fundamentally we do not believe the benefit is great enough to outweigh the cost of the new syntax. The benefits of the new syntax as outlined in the PEP are not particularly strong, and community support for the new syntax seems low. The new syntax doesn’t provide an obvious way to do something that is currently error-prone, and doesn’t open up new possibilities that were not possible before. While there are certainly cases that could use the new syntax, for many of them it’s not clear that it would be a win, or that third-party libraries would indeed use the syntax. The Steering Council isn’t really convinced by any of the suggested uses in the PEP. The strongest argument for the new syntax comes from the typing side of Python. The Steering Council is not particularly convinced it is of significant benefit to the static type checking language, but even if it were, at this point we’re reluctant to add general Python syntax that only (or mostly) benefits the static typing language. If the syntax would be of great benefit to static typing, it might be time to discuss letting go of the requirement that the typing language be a subset of Python -- but whether this feature is important enough to consider that is up to the typing community. The SC considers the cost of the new syntax significant. It’s not a natural fit, as shown by the corner cases discussed in the PEP. It’s difficult to teach, as indexing and function calls are not as interchangeable or equivalent as they may appear. Looking at more complex expressions with the new syntax, mentally parsing them is significantly harder than the equivalent without the new syntax, even if it requires more lines of code to do the same thing. In addition to all that, the SC is worried about the performance of indexing in CPython and in other Python implementations, considering it’s a very common operation, and about the suggested new __getitem__ protocol, particularly the confusing corner cases of indexing with keywords and zero or one positional items. These are not, however, the main reason we decided to reject the PEP. With our appreciation, For the whole Python Steering Council, Thomas. -- Thomas Wouters <thomas@python.org> Hi! I'm an email virus! Think twice before sending your email to help me spread!
Let me clarify what the typing-sig folks wanted out of this PEP. We only care about adding support for `x[*y]` (including things like `x[a, *b, c]`). We'll just update PEP 646 to add that explicitly there and hope that PEP 646 fares better than PEP 637. To fans of PEP 637 I would call out that the main reason for rejection seems to be this paragraph: The benefits of the new syntax as outlined in the PEP are not particularly
strong, and community support for the new syntax seems low. The new syntax doesn’t provide an obvious way to do something that is currently error-prone, and doesn’t open up new possibilities that were not possible before. While there are certainly cases that could use the new syntax, for many of them it’s not clear that it would be a win, or that third-party libraries would indeed use the syntax. The Steering Council isn’t really convinced by any of the suggested uses in the PEP.
This seems to imply that in order for a proposal like this to fare better in the future, the authors would need to line up support from specific, important communities like the scientific, data science or machine learning communities. Currently such support seems absent except for one specific package (xarray). -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
El lun, 15 mar 2021 a las 13:13, Guido van Rossum (<guido@python.org>) escribió:
Let me clarify what the typing-sig folks wanted out of this PEP. We only care about adding support for `x[*y]` (including things like `x[a, *b, c]`). We'll just update PEP 646 to add that explicitly there and hope that PEP 646 fares better than PEP 637.
To fans of PEP 637 I would call out that the main reason for rejection seems to be this paragraph:
The benefits of the new syntax as outlined in the PEP are not particularly
strong, and community support for the new syntax seems low. The new syntax doesn’t provide an obvious way to do something that is currently error-prone, and doesn’t open up new possibilities that were not possible before. While there are certainly cases that could use the new syntax, for many of them it’s not clear that it would be a win, or that third-party libraries would indeed use the syntax. The Steering Council isn’t really convinced by any of the suggested uses in the PEP.
This seems to imply that in order for a proposal like this to fare better in the future, the authors would need to line up support from specific, important communities like the scientific, data science or machine learning communities. Currently such support seems absent except for one specific package (xarray).
Yes, I was surprised to read the focus on typing in the rejection notice because my recollection from the discussions around PEP 637 was that typing was not in fact the major motivation, named column indexing was.
Looking at the PEP's motivation section now ( https://www.python.org/dev/peps/pep-0637/#use-cases), two (#2 and #7) are about typing. #2 ("MyType[T=int]") is rather weak, since "T=int" doesn't provide any increase in clarity over just "int". #7 (PEP 646) is stronger, but was tacked on later and doesn't provide much detail. Among the other use cases, #1 and #3 are quite general. The compelling ones to me are #4 (pandas), #5 (xarray) and #7 (trio.run and similar functions). Focusing more on these use cases would have made the PEP's motivation more similar to matrix multiplication (PEP 465): helping the scientific Python stack make a construct that's currently awkward more simple.
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/MOXRTWGV... Code of Conduct: http://python.org/psf/codeofconduct/
I think this is really the crux of the rejection: is the new syntax being proposed primarily to support typing, or Python in general? Does it help both, or is one use case the motivating factor, and the other is just piggybacking on the syntactic proposal? Quoting from the rejection email:
The strongest argument for the new syntax comes from the typing side of Python. The Steering Council is not particularly convinced it is of significant benefit to the static type checking language, but even if it were, at this point we’re reluctant to add general Python syntax that only (or mostly) benefits the static typing language. If the syntax would be of great benefit to static typing, it might be time to discuss letting go of the requirement that the typing language be a subset of Python -- but whether this feature is important enough to consider that is up to the typing community.
The SC didn’t find general Python functionality compelling enough, or outweighing the costs. It’s possible that the proposed syntax is really useful for typing, and less compelling for Python users in general. And that’s totally fine, but then we’ll need to discuss whether the typing language and the general Python syntax needs to continue to track. Cheers, -Barry
On Mar 15, 2021, at 13:07, Guido van Rossum <guido@python.org> wrote:
Let me clarify what the typing-sig folks wanted out of this PEP. We only care about adding support for `x[*y]` (including things like `x[a, *b, c]`). We'll just update PEP 646 to add that explicitly there and hope that PEP 646 fares better than PEP 637.
To fans of PEP 637 I would call out that the main reason for rejection seems to be this paragraph:
The benefits of the new syntax as outlined in the PEP are not particularly strong, and community support for the new syntax seems low. The new syntax doesn’t provide an obvious way to do something that is currently error-prone, and doesn’t open up new possibilities that were not possible before. While there are certainly cases that could use the new syntax, for many of them it’s not clear that it would be a win, or that third-party libraries would indeed use the syntax. The Steering Council isn’t really convinced by any of the suggested uses in the PEP.
This seems to imply that in order for a proposal like this to fare better in the future, the authors would need to line up support from specific, important communities like the scientific, data science or machine learning communities. Currently such support seems absent except for one specific package (xarray).
-- --Guido van Rossum (python.org/~guido) Pronouns: he/him (why is my pronoun here?) _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/MOXRTWGV... Code of Conduct: http://python.org/psf/codeofconduct/
Actually, the key part of the new syntax, x[a=b], is not useful for typing, at least it's not something that's been discussed in the typing-sig at all. The only part we want is x[*y]. On Mon, Mar 15, 2021 at 3:27 PM Barry Warsaw <barry@python.org> wrote:
I think this is really the crux of the rejection: is the new syntax being proposed primarily to support typing, or Python in general? Does it help both, or is one use case the motivating factor, and the other is just piggybacking on the syntactic proposal? Quoting from the rejection email:
The strongest argument for the new syntax comes from the typing side of Python. The Steering Council is not particularly convinced it is of significant benefit to the static type checking language, but even if it were, at this point we’re reluctant to add general Python syntax that only (or mostly) benefits the static typing language. If the syntax would be of great benefit to static typing, it might be time to discuss letting go of the requirement that the typing language be a subset of Python -- but whether this feature is important enough to consider that is up to the typing community.
The SC didn’t find general Python functionality compelling enough, or outweighing the costs.
It’s possible that the proposed syntax is really useful for typing, and less compelling for Python users in general. And that’s totally fine, but then we’ll need to discuss whether the typing language and the general Python syntax needs to continue to track.
Cheers, -Barry
On Mar 15, 2021, at 13:07, Guido van Rossum <guido@python.org> wrote:
Let me clarify what the typing-sig folks wanted out of this PEP. We only care about adding support for `x[*y]` (including things like `x[a, *b, c]`). We'll just update PEP 646 to add that explicitly there and hope that PEP 646 fares better than PEP 637.
To fans of PEP 637 I would call out that the main reason for rejection seems to be this paragraph:
The benefits of the new syntax as outlined in the PEP are not particularly strong, and community support for the new syntax seems low. The new syntax doesn’t provide an obvious way to do something that is currently error-prone, and doesn’t open up new possibilities that were not possible before. While there are certainly cases that could use the new syntax, for many of them it’s not clear that it would be a win, or that third-party libraries would indeed use the syntax. The Steering Council isn’t really convinced by any of the suggested uses in the PEP.
This seems to imply that in order for a proposal like this to fare better in the future, the authors would need to line up support from specific, important communities like the scientific, data science or machine learning communities. Currently such support seems absent except for one specific package (xarray).
-- --Guido van Rossum (python.org/~guido) Pronouns: he/him (why is my pronoun here?) _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/MOXRTWGV... Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
All right. Thanks for the feedback. Brandt should we terminate the branch, or restructure it for the *args mechanics? On Mon, 15 Mar 2021 at 18:43, Thomas Wouters <thomas@python.org> wrote:
Hi Stefano,
Thank you for submitting PEP 637 (Support for indexing with keyword arguments). The Steering Council has reviewed the PEP and after careful consideration, we have decided to reject the PEP. There are a number of reasons for this, but fundamentally we do not believe the benefit is great enough to outweigh the cost of the new syntax.
The benefits of the new syntax as outlined in the PEP are not particularly strong, and community support for the new syntax seems low. The new syntax doesn’t provide an obvious way to do something that is currently error-prone, and doesn’t open up new possibilities that were not possible before. While there are certainly cases that could use the new syntax, for many of them it’s not clear that it would be a win, or that third-party libraries would indeed use the syntax. The Steering Council isn’t really convinced by any of the suggested uses in the PEP.
The strongest argument for the new syntax comes from the typing side of Python. The Steering Council is not particularly convinced it is of significant benefit to the static type checking language, but even if it were, at this point we’re reluctant to add general Python syntax that only (or mostly) benefits the static typing language. If the syntax would be of great benefit to static typing, it might be time to discuss letting go of the requirement that the typing language be a subset of Python -- but whether this feature is important enough to consider that is up to the typing community.
The SC considers the cost of the new syntax significant. It’s not a natural fit, as shown by the corner cases discussed in the PEP. It’s difficult to teach, as indexing and function calls are not as interchangeable or equivalent as they may appear. Looking at more complex expressions with the new syntax, mentally parsing them is significantly harder than the equivalent without the new syntax, even if it requires more lines of code to do the same thing.
In addition to all that, the SC is worried about the performance of indexing in CPython and in other Python implementations, considering it’s a very common operation, and about the suggested new __getitem__ protocol, particularly the confusing corner cases of indexing with keywords and zero or one positional items. These are not, however, the main reason we decided to reject the PEP.
With our appreciation, For the whole Python Steering Council, Thomas. -- Thomas Wouters <thomas@python.org>
Hi! I'm an email virus! Think twice before sending your email to help me spread!
-- Kind regards, Stefano Borini
participants (5)
-
Barry Warsaw -
Guido van Rossum -
Jelle Zijlstra -
Stefano Borini -
Thomas Wouters