[Python-Dev] Re: PEP 674 – Disallow using macros as l-value (version 2)
On Thu, Jan 27, 2022 at 1:14 AM Larry Hastings wrote: > Just so I understand: is this effectively permanent? My first thought was, > we get SWIG to change its code generation, and in a couple of years we can > follow up and make this change. But perhaps there's so much SWIG code out > there already, and the change would propagate so slowly, that it's not even > worth considering. Is it something like that? Or is it just that it's such > a minor change that it's not worth fighting about? I'm interested to be able to change Python core structures like PyObject, PyTypeObject or PyListObject. It's just that PyDescrObject is out of my scope for now. As you explained, changing SWIG is not free, so it's better to have a good reason to do it :-) If someone wants to do it, I already did the work, I attached patches to: https://bugs.python.org/issue46538 -- About generated code, there is a similar concern with Cython. Hopefully, it seems like maintainers do regenerate the C code of their project using a recent Cython when they release a new version of their project (ex: numpy). So for Cython, fixing Cython is enough, then it's just a matter of time. In the case of the PEP 674, I already updated Cython in May 2020, and Cython is already released with my changes ;-) Victor -- Night gathers, and now my watch begins. It shall not end until my death. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/CTQU7LNZF2FXA34XCWIRXJHUYEKFXCAF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 674 – Disallow using macros as l-value (version 2)
On 1/26/22 3:02 PM, Victor Stinner wrote: Hi, My PEP 674 proposed to change PyDescr_TYPE() and PyDescr_NAME() macros. This change breaks M2Crypto and mecab-python3 projects in code generated by SWIG. I tried two solutions to prevent SWIG accessing PyDescrObject members directly: https://bugs.python.org/issue46538 At the end, IMO it's too much work, whereas there is no need in the short term to modify the PyDescrObject structure, or structure inheriting from PyDescrObject. So I excluded PyDescr_TYPE() and PyDescr_NAME() macros from PEP 674 to leave them unchanged: https://python.github.io/peps/pep-0674/#pydescr-name-and-pydescr-type-are-left-unchanged Just so I understand: is this effectively permanent? My first thought was, we get SWIG to change its code generation, and in a couple of years we can follow up and make this change. But perhaps there's so much SWIG code out there already, and the change would propagate so slowly, that it's not even worth considering. Is it something like that? Or is it just that it's such a minor change that it's not worth fighting about? //arry/ p.s. thanks for doing this! ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/KQD4MW2DIFQYDYP25Z6A5XHQHZW75NEV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 674 – Disallow using macros as l-value (version 2)
Hi, My PEP 674 proposed to change PyDescr_TYPE() and PyDescr_NAME() macros. This change breaks M2Crypto and mecab-python3 projects in code generated by SWIG. I tried two solutions to prevent SWIG accessing PyDescrObject members directly: https://bugs.python.org/issue46538 At the end, IMO it's too much work, whereas there is no need in the short term to modify the PyDescrObject structure, or structure inheriting from PyDescrObject. So I excluded PyDescr_TYPE() and PyDescr_NAME() macros from PEP 674 to leave them unchanged: https://python.github.io/peps/pep-0674/#pydescr-name-and-pydescr-type-are-left-unchanged Today, the PEP 674 only affects 9 projects on the top 5000 PyPI projects (+ 22 projects which have to re-run Cython). Victor ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/SKZ5UTNJD3AAYIBTL6D4Y7XKGI2PZSIF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Request to revert unittest and configparser incompatible changes in Python 3.11
On 2022-01-18 23:14, Gregory P. Smith wrote: Our stdlib unittest already enables warnings by default per https://bugs.python.org/issue10535. Getting the right people to pay attention to them is always the hard part. I wonder if we can do a bit better in that regard. When I install 3rd party packages, I create a usercustomize.py file that uses filterwarnings() to turn off all the warnings I don't care about. I don't know how but maybe we could make that easier to do. That way, you don't get buried in warnings coming from code you don't maintain. Additionally, maybe we should be more aggressive about showing PendingDeprecationWarning if it comes from code that seems to be written by the user, e.g. outside site-packages or not from a package installed by pip. The exact logic of that is complicated though. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/HB4ZSI5UWSI3R3ASTIOCAYNU7YPBB57F/ Code of Conduct: http://python.org/psf/codeofconduct/
