This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients christian.heimes, gvanrossum, pacampbell, paul.moore, steve.dower, tim.golden, vstinner, zach.ware
Date 2022-01-12.00:15:09
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1641946509.64.0.114951815108.issue46303@roundup.psfhosted.org>
In-reply-to
Content
> Hi Victor, I was trying to compile with clang on Windows 10. I will try to pull your 3.11 changes and test. Sorry to cause so much churn. It looked to me like a simple issue that was missed, probably because whatever was trying to compile was not normally compiled on Windows. I was not trying to make a lot of work to support a new platform :)

I tried to write a change which doesn't increase the maintenance on other platforms.

I dislike declaring private functions in the *public* Python.h header file, especially if they cause build error. Over the last years, I moved many private functions to the internal C API.

In Python, we are trying to provide a same C API on all platforms. If "struct stat" is no longer considered as portable, IMO we should attempt to avoid it, at least in the public C API. For these reasons, I dislike PR 30478. The problem is that if the work is written on Linux using "strut stat", the build can fail on Windows if "struct _Py_stat_struct" is now required on Windows. I expected "struct stat" to be portable, but it seems like I was wrong.
History
Date User Action Args
2022-01-12 00:15:09vstinnersetrecipients: + vstinner, gvanrossum, paul.moore, christian.heimes, tim.golden, zach.ware, steve.dower, pacampbell
2022-01-12 00:15:09vstinnersetmessageid: <1641946509.64.0.114951815108.issue46303@roundup.psfhosted.org>
2022-01-12 00:15:09vstinnerlinkissue46303 messages
2022-01-12 00:15:09vstinnercreate