Message389907
| Author |
vstinner |
| Recipients |
mark.dickinson, vstinner |
| Date |
2021年03月31日.14:44:15 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1617201855.54.0.564755127224.issue43682@roundup.psfhosted.org> |
| In-reply-to |
| Content |
> Seems like a duplicate of #20309.
My usecase is to avoid any behavior difference between io.open and _pyio.open functions: PEP 399 "Pure Python/C Accelerator Module Compatibility Requirements". Currently, this is a very subtle difference when it's used to define a method.
I dislike the current _pyio.OpenWrapper "hack". I would prefer that _pyio.open would be directly usable to define a method. I propose to use @staticmethod, but I am open to other ideas. It could be a new decorator: @staticmethod_or_function.
Is it worth it to introduce a new @staticmethod_or_function decorator just to leave @staticmethod unchanged?
Note: The PEP 570 "Python Positional-Only Parameters" (implemented in Python 3.8) removed another subtle difference between functions implemented in C and functions implemented in Python. Now functions implemented in Python can only have positional only parameters. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2021年03月31日 14:44:15 | vstinner | set | recipients:
+ vstinner, mark.dickinson |
| 2021年03月31日 14:44:15 | vstinner | set | messageid: <1617201855.54.0.564755127224.issue43682@roundup.psfhosted.org> |
| 2021年03月31日 14:44:15 | vstinner | link | issue43682 messages |
| 2021年03月31日 14:44:15 | vstinner | create |
|