Hi all,
PEP 535 was deferred until Python 3.8. I would like to discuss the PEP given that some time has passed, and I _personally_ would benefit from its acceptance.
## A little about me:
As a reasonably long-time Python user (well, 16 years), I have gradually moved from using only the core language to working within the DSLs (NumPy et al.) of the Scientific Python ecosystem. Most recently, I've been using Awkward Arrray (https://github.com/scikit-hep/awkward-1.0), which generalises the regular NumPy array programming paradigm into "jagged" data structures, and was initially aimed at the High Energy Physics (HEP) domain.
## TL;DR of the PEP's Motivations:
Various aspects of NumPy's API have become a "lingua-franca" in the Scientific Python domain, such as strongly-overloaded index operations. One such overload allows "mask arrays" — arrays with boolean entries corresponding to a per-element mask — to select a subset of the array. These mask arrays are conveniently built from the rich comparison operators that Python supports, e.g.
```python
x = np.array(...)
y = x[(2 < x) & (x < 8)]
```
As discussed in PEP 535, the limitation on comparison chaining (namely that it is not possible for rich comparisons) makes the above syntax more clunky than it might otherwise be. The main repercussion of this limitation is lower readability:
- operator precedence of bitwise and/or requires a reasonable number of parentheses (https://docs.python.org/3/reference/expressions.html#operator-precedence)
- repetition of the rich-object (array)
With PEP 535 (and the necessary library changes), this would look more like
```python
x = np.array(...)
y = x[2 < x < 8]
```
This is already well described in the PEP, so I'll leave the example there!
## Community Survey
The Oct 2020 Python Developers Survey (https://www.jetbrains.com/lp/python-developers-survey-2020/) suggests that 62% of respondents use NumPy. Additionally, 37% of respondents list "Simple syntax, syntactic sugar, easy to learn" and 30% list "Easy to write & read code, high-level language" amongst their three most liked features in the Python language (to clarify, these answers may overlap by respondent!)
>From these results, I would make a tentative case that this PEP would have a reasonable impact on the Python community, given that libraries benefitting from this proposal (e.g. NumPy) are used by a "majority" of those surveyed.
## Conclusion
This is a bit of a long opener to this list (apologies!). Is there any interest in pushing this PEP along?
Thanks,
Angus Hollands
_______________________________________________
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/ET7BPR57Q6MT6TUG4SXPSALRC3P3ZY35/
Code of Conduct: http://python.org/psf/codeofconduct/
PEP 535 was deferred until Python 3.8. I would like to discuss the PEP given that some time has passed, and I _personally_ would benefit from its acceptance.
## A little about me:
As a reasonably long-time Python user (well, 16 years), I have gradually moved from using only the core language to working within the DSLs (NumPy et al.) of the Scientific Python ecosystem. Most recently, I've been using Awkward Arrray (https://github.com/scikit-hep/awkward-1.0), which generalises the regular NumPy array programming paradigm into "jagged" data structures, and was initially aimed at the High Energy Physics (HEP) domain.
## TL;DR of the PEP's Motivations:
Various aspects of NumPy's API have become a "lingua-franca" in the Scientific Python domain, such as strongly-overloaded index operations. One such overload allows "mask arrays" — arrays with boolean entries corresponding to a per-element mask — to select a subset of the array. These mask arrays are conveniently built from the rich comparison operators that Python supports, e.g.
```python
x = np.array(...)
y = x[(2 < x) & (x < 8)]
```
As discussed in PEP 535, the limitation on comparison chaining (namely that it is not possible for rich comparisons) makes the above syntax more clunky than it might otherwise be. The main repercussion of this limitation is lower readability:
- operator precedence of bitwise and/or requires a reasonable number of parentheses (https://docs.python.org/3/reference/expressions.html#operator-precedence)
- repetition of the rich-object (array)
With PEP 535 (and the necessary library changes), this would look more like
```python
x = np.array(...)
y = x[2 < x < 8]
```
This is already well described in the PEP, so I'll leave the example there!
## Community Survey
The Oct 2020 Python Developers Survey (https://www.jetbrains.com/lp/python-developers-survey-2020/) suggests that 62% of respondents use NumPy. Additionally, 37% of respondents list "Simple syntax, syntactic sugar, easy to learn" and 30% list "Easy to write & read code, high-level language" amongst their three most liked features in the Python language (to clarify, these answers may overlap by respondent!)
>From these results, I would make a tentative case that this PEP would have a reasonable impact on the Python community, given that libraries benefitting from this proposal (e.g. NumPy) are used by a "majority" of those surveyed.
## Conclusion
This is a bit of a long opener to this list (apologies!). Is there any interest in pushing this PEP along?
Thanks,
Angus Hollands
_______________________________________________
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/ET7BPR57Q6MT6TUG4SXPSALRC3P3ZY35/
Code of Conduct: http://python.org/psf/codeofconduct/