[Python-Dev] Re: Request for feedback: pathlib.AbstractPath prototype
On Thu, 10 Feb 2022 at 21:45, Brett Cannon wrote: > > > On Wed, Feb 9, 2022 at 11:59 AM Barney Gale wrote: > >> Penny for your thoughts on those questions, Brett? Protocols are new to >> me. I see importlib.abc.Traversable is a Protocol, and I'm giving PEP 544 a >> read now. >> > > Protocols would let folks rely on a common Path object API w/o having to > require the object come from pathlib itself or explicitly subclass > something (which I admit would be rare, but there's no reason to > artificially constrain this either). Now maybe this is too broad of an API > for people to care, but since protocols are also ABCs it doesn't inherently > make things worse, either. So I would say subclassing Protocol makes sense > while still using abc.abstractmethod for methods people must implement. > > Thanks Brett. My only concern there is that the protocol would be /extensive/, encompassing all PurePath + Path methods. It's rather impractical to write a Path-compatible class without subclassing something from pathlib - and that impracticality is one motivation for this work! PEP 544 seems to make this point: > Protocol classes should generally not have many method implementations, as they describe an interface, not an implementation. Most classes have many method implementations, making them bad protocol classes. https://www.python.org/dev/peps/pep-0544/#make-every-class-a-protocol-by-default For now I've made _AbstractPath inherit abc.ABC, but I'm open to consider it further! Barney On Thu, 10 Feb 2022 at 21:45, Brett Cannon wrote: > > > On Wed, Feb 9, 2022 at 11:59 AM Barney Gale wrote: > >> Penny for your thoughts on those questions, Brett? Protocols are new to >> me. I see importlib.abc.Traversable is a Protocol, and I'm giving PEP 544 a >> read now. >> > > Protocols would let folks rely on a common Path object API w/o having to > require the object come from pathlib itself or explicitly subclass > something (which I admit would be rare, but there's no reason to > artificially constrain this either). Now maybe this is too broad of an API > for people to care, but since protocols are also ABCs it doesn't inherently > make things worse, either. So I would say subclassing Protocol makes sense > while still using abc.abstractmethod for methods people must implement. > > >> >> I reckon only stat(), open() and iterdir() would be essential for users >> to implement. >> > > Seems like a reasonable set to have to implement. > > -Brett > > >> >> On Wed, 9 Feb 2022 at 19:02, Brett Cannon wrote: >> >>> One thing to discuss (and which has been brought up on the PR), is >>> whether this should be an ABC to force people to explicitly raise >>> `NotImplementedError`? >>> >>> The next question is whether any of this should be a (very wide) >>> protocol instead of an ABC? >>> >>> On Wed, Feb 9, 2022 at 7:05 AM Barney Gale >>> wrote: >>> Over the last couple of years I've been tidying up the pathlib internals, with a view towards adding an AbstractPath class to the hierarchy. Users would be able to subclass AbstractPath to implement other kinds of filesystems: s3, google cloud storage, pandas, ftp, git, zip and tar files, etc. By implementing some abstract methods (stat(), iterdir(), open(), etc) they'd benefit from a number of derived methods (is_dir(), glob(), read_text(), etc). There's already a healthy ecosystem of PyPI packages attempting this, but there's presently no officially-supported route. I've now submitted a PR that adds an initial underscore-prefixed implementation of this class: https://github.com/python/cpython/pull/31085. The implementation is simple: wherever Path calls functions in os, io, pwd, etc, AbstractPath instead raises NotImplementedError. The Path class becomes an implementation of AbstractPath. These methods directly raise NotImplementedError: cwd(), stat(), iterdir(), readlink(), resolve(), expanduser(), owner(), group(), open(), touch(), mkdir(), symlink_to(), hardlink_to(), rename(), replace(), chmod(), unlink(), rmdir() These methods call through to the above methods: absolute(), lstat(), exists(), is_dir(), is_file(), is_mount(), is_symlink(), is_block_device(), is_char_device(), is_fifo(), is_socket(), home(), samefile(), scandir(), glob(), rglob(), read_bytes(), read_text(), write_bytes(), write_text(), lchmod(), link_to() Some methods aren't applicable to some kinds of filesystems, e.g. zip files don't support symlinks, working directories or home directories. In these cases I think it's reasonable to raise NotImplementedError. Indeed, pathlib.Path methods already raise NotImplementedError when certain local filesystem features aren't available (readlink(), group(), etc). If any readers of this list have previously tried to extend pathlib to other domains, or are otherwise interested in pathlib
[Python-Dev] Re: Move the pythoncapi_compat project under the GitHub Python or PSF organization?
On 2022-02-11 06:14, Petr Viktorin wrote: Sounds reasonable, but... The implication of endorsing code like this is that *we cannot change private API even in patch releases*, which I don't think is documented anywhere, and might be a bit controversial. I think we are still allowed to change them. We should be aware of the impact though. If an API is supposed to be private but is actually used by a large number of 3rd party extensions, we need to consider carefully when changing it. I don't have much sympathy for work caused for people using clearly marked private APIs. OTOH, practicality beats purity and we want them to be able to somehow use new versions of Python. ___ 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/7FX3I4XDSXHZY2ZHFHQCVTAVWJL4KDPQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2022-02-04 - 2022-02-11) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open7178 (+34) closed 51272 (+50) total 58450 (+84) Open issues with patches: 2912 Issues opened (63) == #42548: debugger stops at breakpoint of `pass` that is not actually re https://bugs.python.org/issue42548 reopened by iritkatriel #44006: symbol documentation still exists https://bugs.python.org/issue44006 reopened by vstinner #45459: Limited API support for Py_buffer https://bugs.python.org/issue45459 reopened by vstinner #46430: intern strings in deepfrozen modules https://bugs.python.org/issue46430 reopened by christian.heimes #46639: Ceil division with math.ceildiv https://bugs.python.org/issue46639 opened by Vladimir Feinberg #46640: Python can now use the C99 NAN constant or __builtin_nan() https://bugs.python.org/issue46640 opened by vstinner #46642: typing: tested TypeVar instance subclass TypeError is incident https://bugs.python.org/issue46642 opened by GBeauregard #46643: typing.Annotated cannot wrap typing.ParamSpec args/kwargs https://bugs.python.org/issue46643 opened by GBeauregard #46644: typing: remove callable() check from typing._type_check https://bugs.python.org/issue46644 opened by GBeauregard #46645: Portable python3 shebang for Windows, macOS, and Linux https://bugs.python.org/issue46645 opened by joshtriplett #46646: `address` arg can be `bytes` for `ip_*` functions in `ipaddres https://bugs.python.org/issue46646 opened by sobolevn #46649: Propagate Python thread name to thread state structure https://bugs.python.org/issue46649 opened by Gabriele Tornetta #46650: `priority` in `sched.scheduler` is not sufficiently tested https://bugs.python.org/issue46650 opened by sobolevn #46652: Use code.co_qualname to provide richer information https://bugs.python.org/issue46652 opened by Gabriele Tornetta #46653: sys.path entries normalization in site.py doesn't follow POSIX https://bugs.python.org/issue46653 opened by jpoiret #46654: urllib.request.urlopen doesn't handle UNC paths produced by pa https://bugs.python.org/issue46654 opened by ikelos #46655: typing.TypeAlias is not in the list of allowed plain _SpecialF https://bugs.python.org/issue46655 opened by GBeauregard #46656: Compile fails if Py_NO_NAN is defined https://bugs.python.org/issue46656 opened by mark.dickinson #46657: Add mimalloc memory allocator https://bugs.python.org/issue46657 opened by christian.heimes #46658: shutil Lib enables sendfile on solaris for regular files https://bugs.python.org/issue46658 opened by devnexen #46659: Deprecate locale.getdefaultlocale() function https://bugs.python.org/issue46659 opened by vstinner #46661: Duplicat deprecation warnings in docs for asyncio https://bugs.python.org/issue46661 opened by gvanrossum #46662: Lib/sqlite3/dbapi2.py: convert_timestamp function failed to co https://bugs.python.org/issue46662 opened by Rayologist #46663: test_math test_cmath test_complex fails on Fedora Rawhide buil https://bugs.python.org/issue46663 opened by vstinner #46664: PY_SSIZE_T_MAX is not an integer constant expression https://bugs.python.org/issue46664 opened by ov2k #46665: IDLE Windows shortcuts by default https://bugs.python.org/issue46665 opened by primexx #4: IDLE Add indent guide https://bugs.python.org/issue4 opened by primexx #46667: SequenceMatcher & autojunk - false negative https://bugs.python.org/issue46667 opened by jonathan-lp #46668: encodings: the "mbcs" alias doesn't work https://bugs.python.org/issue46668 opened by vstinner #46670: Build Python with -Wundef: don't use undefined macros https://bugs.python.org/issue46670 opened by vstinner #46671: "ValueError: min() arg is an empty sequence" is wrong (builtin https://bugs.python.org/issue46671 opened by Nnarol #46672: NameError in asyncio.gather when passing a invalid type as an https://bugs.python.org/issue46672 opened by onerandomusername #46675: Allow more than 16 items in split-keys dicts and "virtual" obj https://bugs.python.org/issue46675 opened by Mark.Shannon #46677: TypedDict docs are incomplete https://bugs.python.org/issue46677 opened by Jelle Zijlstra #46679: test.support.wait_process ignores timeout argument https://bugs.python.org/issue46679 opened by notarealdeveloper #46681: gzip.compress does not forward compresslevel to zlib.compress https://bugs.python.org/issue46681 opened by iii-i #46682: python 3.10 Py_Initialize/Py_Main std path no longer includes https://bugs.python.org/issue46682 opened by pjaggi1 #46685: Add additional tests for new features in `typing.py` https://bugs.python.org/issue46685 opened by sobolevn #46686: [venv / PC/launcher] issue with a space in the installed pytho https://bugs.python.org/issue46686 opened by hokiedsp #46689:
[Python-Dev] Re: Request for feedback: pathlib.AbstractPath prototype
On Thu, Feb 10, 2022 at 2:15 PM Ethan Furman wrote: > On 2/10/22 1:45 PM, Brett Cannon wrote: > > > Protocols would let folks rely on a common Path object API w/o having > to require the object > > come from pathlib itself or explicitly subclass something (which I > admit would be rare, but > > there's no reason to artificially constrain this either). Now maybe > this is too broad of an > > API for people to care, but since protocols are also ABCs it doesn't > inherently make things > > worse, either. So I would say subclassing Protocol makes sense while > still using > > abc.abstractmethod for methods people must implement. > > Brett, when you say Protocol are you referring to static typing? Yep, specifically https://docs.python.org/3/library/typing.html#typing.Protocol . > In your earlier email I thought you were referring to > building blocks such as _fs_path, or the __iter__ and __next__ protocols. > Technically those are *special methods* that define a protocol (obviously `typing.Protocol` got its name from somewhere ). But it's all the same concept: defining what methods you expect an object to have. ___ 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/IGYMVZYNQZZ2PXBQTOIG7TVJVZWFNLYI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Move the pythoncapi_compat project under the GitHub Python or PSF organization?
On Fri, Feb 11, 2022 at 3:14 PM Petr Viktorin wrote: > Sounds reasonable, but... > > The implication of endorsing code like this is that *we cannot change > private API even in patch releases*, which I don't think is documented > anywhere, and might be a bit controversial. > (I'm still planning to document this along with other similar issues, so > if anyone wants to help here, please coordinate with me: > https://discuss.python.org/t/documenting-python-versioning-and-stability-expectations/11090/4). Maybe... we should not do that :-D The PyGC_Head ABI change was the most controversial, but it was already part of the private API and the following bug was closed as "not a bug": https://bugs.python.org/issue39599 This structure now belings to the *internal* C API. > Since you're now inviting the wider community as co-maintainers, could > you document this? Well, anyone is welcomed to contribute! 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/WZTVXVBSYS5J3PITADSIYI32KZEJS2MR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Move the pythoncapi_compat project under the GitHub Python or PSF organization?
On 11. 02. 22 13:52, Victor Stinner wrote:
On Fri, Feb 11, 2022 at 12:06 PM Petr Viktorin wrote:
Or will this send a message that core devs should co-maintain the project?
I personally wouldn't want to maintain it, but it it looks like there
are at least 3 maintainers who do.
I think that Neal provided a better answer than me :-) It would be
great than once an incompatible C API change is introduced in Python,
pythoncapi_compat is updated. Updating pythoncapi_compat (with unit
tests) ensures that it *is* possible to write a single code base
compatible with old and new Python versions. Sometimes the change can
be modified just a little it to make that transition smoother.
In the past, that's exactly what I did. When I wrote
PyThreadState_EnterTracing(), I started to create a draft PR for
pythoncapi_compat. I merged the pythoncapi_compat PR once the API
landed in Python. I did that for other new C API functions.
All sounds good, I just insist on pointing out that this was only an
incompatible change in the *internal* API.
The functionality of PyThreadState_EnterTracing() was not possible to
get with public API, but enough third parties “cheated”** and used
private API to make it worth writing an automatic updater.
** Or maybe they read an older version of the docs where this wasn't
clear, and then had compatibility expectations changed beneath them. The
way we've been drawing lines between public and private in the past few
years is not entirely fair, but it's the best we have.
Note that PyFrame_* and PyThreadState_* replace API that was previously
private (specifically, documented as subject to change at any time).
I think pythoncapi_compat is a good tool to run if you used code like that!
My goal for pythoncapi_compat is to only support new *public*
functions. The *implementation* can use the private API. So C
extensions can use the new clean API and remains compatible with old
Python versions using private structures and private functions.
For example, the PyThreadState_EnterTracing() implementation uses
PyThreadState.cframe.use_tracing (Python 3.10) or
PyThreadState.use_tracing (Python 3.9 and older), and also
PyThreadState.cframe.tracing, whereas the PyThreadState structure is
considered as "private".
// bpo-43760 added PyThreadState_EnterTracing() to Python 3.11.0a2
#if PY_VERSION_HEX < 0x030B00A2 && !defined(PYPY_VERSION)
PYCAPI_COMPAT_STATIC_INLINE(void)
PyThreadState_EnterTracing(PyThreadState *tstate)
{
tstate->tracing++;
#if PY_VERSION_HEX >= 0x030A00A1
tstate->cframe->use_tracing = 0;
#else
tstate->use_tracing = 0;
#endif
}
#endif
Sounds reasonable, but...
The implication of endorsing code like this is that *we cannot change
private API even in patch releases*, which I don't think is documented
anywhere, and might be a bit controversial.
(I'm still planning to document this along with other similar issues, so
if anyone wants to help here, please coordinate with me:
https://discuss.python.org/t/documenting-python-versioning-and-stability-expectations/11090/4).
Note that the upgrade_pythoncapi script uses regular expressions to turn
e.g. all occurences of `something->interp` to
`PyThreadState_GetInterpreter(something)`.
It's fairly simple, but works in practice -- you aren't likely to have
another struct with a `interp` member. IOW, you do need to do a thorough
review after running it, as with a PR from a human contributor. But I
don't think anyone a expects a *fully* automated solution, do they?
Right, currently the script uses regex because it's built in Python:
no third party dependency needed. So far, I didn't have to make any
further changes after the script updated a C extension.
In general, only a few lines number of lines are modified by the
script. Less than 50: 5 to 10 lines on most C extensions.
The question of maintenance brings op questions about the scope and
backwards compatibility of pythoncapi_compat itself. Currently there's
partial support for Python 2.7, and full for 3.5+. Will the fixes stay
in and accumulate indefinitely?
Supporting 2.7 and 3.5 is cheap: the code is already written. I plan
to continue supporting them until it breaks. Once it will no longer be
possible to test these versions, maybe the code can stay, untested,
and bugs would only be fixed if someone proposes a fix.
Makes sense!
Since you're now inviting the wider community as co-maintainers, could
you document this?
It just added Python 3.4 support since it is still possible to get a
Python 3.4 in GitHub Actions (Ubuntu 18.04) :-)
Python 2.7 support is mostly needed by Mercurial which is already
compatible with Python 3. Mercurial plans to drop Python 2 support
soon: in Mercurial 6.2, or maybe even Mercurial 6.1 (the latest
release is 6.0):
https://www.mercurial-scm.org/wiki/Python3
It seems like on Python 3, users target Python 3.6 as the minimum
supported version. Some projects already dropped Python 3.6 support,
move on to Python 3.7.
[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11
IMO we need to distinguish the public C API which should be as much compatible as possible, target the oldest C standard, and the Python internals can require a more recent C standard. For example, today maybe it's reasonable to requires C99 for Include/ headers (public .h files) and support C11 for Python internals (private .c files). 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/LG5WBBU5JK44IO6UCKSQEUVCJ55X6ZBE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Move the pythoncapi_compat project under the GitHub Python or PSF organization?
On Fri, Feb 11, 2022 at 12:06 PM Petr Viktorin wrote:
> Or will this send a message that core devs should co-maintain the project?
> I personally wouldn't want to maintain it, but it it looks like there
> are at least 3 maintainers who do.
I think that Neal provided a better answer than me :-) It would be
great than once an incompatible C API change is introduced in Python,
pythoncapi_compat is updated. Updating pythoncapi_compat (with unit
tests) ensures that it *is* possible to write a single code base
compatible with old and new Python versions. Sometimes the change can
be modified just a little it to make that transition smoother.
In the past, that's exactly what I did. When I wrote
PyThreadState_EnterTracing(), I started to create a draft PR for
pythoncapi_compat. I merged the pythoncapi_compat PR once the API
landed in Python. I did that for other new C API functions.
> Note that PyFrame_* and PyThreadState_* replace API that was previously
> private (specifically, documented as subject to change at any time).
> I think pythoncapi_compat is a good tool to run if you used code like that!
My goal for pythoncapi_compat is to only support new *public*
functions. The *implementation* can use the private API. So C
extensions can use the new clean API and remains compatible with old
Python versions using private structures and private functions.
For example, the PyThreadState_EnterTracing() implementation uses
PyThreadState.cframe.use_tracing (Python 3.10) or
PyThreadState.use_tracing (Python 3.9 and older), and also
PyThreadState.cframe.tracing, whereas the PyThreadState structure is
considered as "private".
// bpo-43760 added PyThreadState_EnterTracing() to Python 3.11.0a2
#if PY_VERSION_HEX < 0x030B00A2 && !defined(PYPY_VERSION)
PYCAPI_COMPAT_STATIC_INLINE(void)
PyThreadState_EnterTracing(PyThreadState *tstate)
{
tstate->tracing++;
#if PY_VERSION_HEX >= 0x030A00A1
tstate->cframe->use_tracing = 0;
#else
tstate->use_tracing = 0;
#endif
}
#endif
> Note that the upgrade_pythoncapi script uses regular expressions to turn
> e.g. all occurences of `something->interp` to
> `PyThreadState_GetInterpreter(something)`.
> It's fairly simple, but works in practice -- you aren't likely to have
> another struct with a `interp` member. IOW, you do need to do a thorough
> review after running it, as with a PR from a human contributor. But I
> don't think anyone a expects a *fully* automated solution, do they?
Right, currently the script uses regex because it's built in Python:
no third party dependency needed. So far, I didn't have to make any
further changes after the script updated a C extension.
In general, only a few lines number of lines are modified by the
script. Less than 50: 5 to 10 lines on most C extensions.
> The question of maintenance brings op questions about the scope and
> backwards compatibility of pythoncapi_compat itself. Currently there's
> partial support for Python 2.7, and full for 3.5+. Will the fixes stay
> in and accumulate indefinitely?
Supporting 2.7 and 3.5 is cheap: the code is already written. I plan
to continue supporting them until it breaks. Once it will no longer be
possible to test these versions, maybe the code can stay, untested,
and bugs would only be fixed if someone proposes a fix.
It just added Python 3.4 support since it is still possible to get a
Python 3.4 in GitHub Actions (Ubuntu 18.04) :-)
Python 2.7 support is mostly needed by Mercurial which is already
compatible with Python 3. Mercurial plans to drop Python 2 support
soon: in Mercurial 6.2, or maybe even Mercurial 6.1 (the latest
release is 6.0):
https://www.mercurial-scm.org/wiki/Python3
It seems like on Python 3, users target Python 3.6 as the minimum
supported version. Some projects already dropped Python 3.6 support,
move on to Python 3.7.
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/XDZUP2ECGFZP5KSJ7ZP5MEJPX7W6UKOK/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Move the pythoncapi_compat project under the GitHub Python or PSF organization?
On 10. 02. 22 23:58, Victor Stinner wrote: Hi, Would it make sense to move the pythoncapi_compat project under the GitHub Python or PSF organization to make it more "official" and a little bit more sustainable? "The pythoncapi_compat project can be used to write a C extension supporting a wide range of Python versions with a single code base. It is made of the pythoncapi_compat.h header file and the upgrade_pythoncapi.py script." Documentation: https://pythoncapi-compat.readthedocs.io/en/latest/ GitHub: https://github.com/pythoncapi/pythoncapi_compat In the past, I managed to move my personal pyperf project under the PSF organization. Now other core developers are contributing and using it. It's better than having it as a personal project. pythoncapi_compat respects the PSF requirements to move a project in the GitHub PSF organization: contributors are required to respect the PSF Code of Conduct and the project has 3 maintainers (Dong-hee Na, Erlend E. AAsland and me). --- Some context. Some additional context: AFAICS, the reason to move it to Python/PSF is to send some kind of signal. The question is, what kind of signal would that be? On the SC issue, Victor said The signal is that the Python core devs bless and trust this project to be a good solution for the problem that it is trying to solve. That sounds reasonable. Do we collectively trust the project? Or will this send a message that core devs should co-maintain the project? I personally wouldn't want to maintain it, but it it looks like there are at least 3 maintainers who do. Incompatible C API changes in Python 3.10 and 3.11 require adding compatibility code to write C code compatible with old and new Python versions. For example, What's New in Python 3.10 suggests adding the following code to your project to get the Py_SET_REFCNT() function on Python 3.9 and older: #if PY_VERSION_HEX < 0x030900A4 # define Py_SET_REFCNT(obj, refcnt) ((Py_REFCNT(obj) = (refcnt)), (void)0) #endif Python 3.11 requires even more compatibility functions (7) and the implementation of these functions take more lines of code: * Py_SET_TYPE() * Py_SET_SIZE() * PyFrame_GetCode() * PyFrame_GetBack() * PyThreadState_GetFrame() * PyThreadState_EnterTracing() * PyThreadState_LeaveTracing() Note that PyFrame_* and PyThreadState_* replace API that was previously private (specifically, documented as subject to change at any time). I think pythoncapi_compat is a good tool to run if you used code like that! My opinion on Py_SET_TYPE is that CPython shouldn't make the change necessary in the first place. But that's in PEP 674, so it's another discussion. Note that the upgrade_pythoncapi script uses regular expressions to turn e.g. all occurences of `something->interp` to `PyThreadState_GetInterpreter(something)`. It's fairly simple, but works in practice -- you aren't likely to have another struct with a `interp` member. IOW, you do need to do a thorough review after running it, as with a PR from a human contributor. But I don't think anyone a expects a *fully* automated solution, do they? The question of maintenance brings op questions about the scope and backwards compatibility of pythoncapi_compat itself. Currently there's partial support for Python 2.7, and full for 3.5+. Will the fixes stay in and accumulate indefinitely? I added a reference to the pythoncapi_compat project to What's New in Python 3.11: "Or use the pythoncapi_compat project to get these functions on old Python functions." https://docs.python.org/dev/whatsnew/3.11.html#c-api-changes The project provides an upgrade_pythoncapi.py script to automatically add Python 3.10 and 3.11 support without losing support with Python 2.7. Just run the script, maybe copy pythoncapi_compat.h, and you're done! :-) It also provides a "pythoncapi_compat.h" header file which contains all the required compatibility code. Just copy the header file and use #include "pythoncapi_compat.h"< in your project. You don't have to maintain this compatibilty code yourself anymore (pythoncapi_compat.h is made of 400 lines of C code). pythoncapi_compat supports Python (2.7 to 3.11), PyPy (2.7, 3.6, 3.7) and C++. It is distributed under the MIT license. My concern is that currently the project lives in my https://github.com/pythoncapi organization which is not really a sustainable option for the future. Why? (That's an honest question.) I have a similar project (just header, not automation) for py2->py3 transition under my *personal* account, and it seems to have been pretty succesful: https://py3c.readthedocs.io/en/latest/ --- The pythoncapi_compat project is used by more and more Python projects, like Mercurial or mypy: https://pythoncapi-compat.readthedocs.io/en/latest/users.html I already made a similar request in June 2021 (move the project under the PSF organization): https://mail.python.org/archives/list/python-dev@python.org/thread/KHDZGCNOYEDUTSPAATUDP55ZSSQM5RRC/
[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11
On Thu, Feb 10, 2022 at 6:31 PM Petr Viktorin wrote: > > > > > I like it. I want to use anonymous union. It makes complex structure > > like PyDictKeysObject simple a little. > > > > I confirmed that XLC supports it. > > https://www.ibm.com/docs/en/xl-c-and-cpp-aix/13.1.3?topic=types-structures-unions#strct__anonstruct > > Ah, I've also wanted anonymous unions in the past! > There's a little problem in that they're not valid in C++, so we can't > have them in public headers. > C++ 11 supports anonymous union with some reasonable limitations. https://en.cppreference.com/w/cpp/language/union XL C/C++ also support it. So we can use it if we decided to use it. Regards, -- Inada Naoki ___ 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/GE3RFUXUDFY3GZQHFEVZAIQW3CCMLFK7/ Code of Conduct: http://python.org/psf/codeofconduct/
