Skip to content

Synced docs and docstring for sysconfig.get_platform #135530

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 10 commits into
base: main
Choose a base branch
from

Conversation

ivanbelenky
Copy link

@ivanbelenky ivanbelenky commented Jun 15, 2025

  • added missing arm64 macos return to sysconfig.get_platform
  • synced docstring and docs for the get_platform

📚 Documentation preview 📚: https://cpython-previews--135530.org.readthedocs.build/

@ivanbelenky ivanbelenky requested a review from FFY00 as a code owner June 15, 2025 05:39
@python-cla-bot
Copy link

python-cla-bot bot commented Jun 15, 2025

All commit authors signed the Contributor License Agreement.

CLA signed

@bedevere-app
Copy link

bedevere-app bot commented Jun 15, 2025

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

@efimov-mikhail
Copy link
Contributor

efimov-mikhail commented Jun 15, 2025

Thanks for the catch!

It seems that still there are some possible return values of sysconfig.get_platform which aren't in the list, macosx-10.3-x86_64, macosx-10.4-universal and win-arm32, for example.
See sysconfig.get_platform at Lib/sysconfig/__init__.py and test_get_platform at Lib/test/test_sysconfig.py.
IMO, all those values should be addressed in the same PR.

Moreover, improving test_get_platform for the new macosx-11.0-arm64 (and maybe other macosx-11.0 versions?) also feels valueable.

On the other hand, general rewording can be more useful.
Remove "will return one of"/"can return" phrases and provide only examples for different platform instead of list of all possible values.

Some links to related previous PRs and commits:
#128701, 1875570

@bedevere-app

This comment was marked as duplicate.

@ivanbelenky ivanbelenky force-pushed the add-macos-docs-get_platform branch from a6537bc to 7ab7580 Compare June 15, 2025 07:51
@bedevere-app

This comment was marked as duplicate.

@ivanbelenky
Copy link
Author

ivanbelenky commented Jun 15, 2025

@efimov-mikhail thanks for your swift response, I also thought that the phrasing "macOs can return" as well as "Examples of returned values" was implicitly assuming that an exhaustive list is not necessary. But did not know if this was intentional or not. I agree that exhaustive is better.

I've added what I think is an exhaustive list + the tests for the >=11 macOS releases. Maybe this is a redundancy. I lack expertise on many aspects of the platform and sysconfig logic, so I may be missing something here.

@efimov-mikhail
Copy link
Contributor

Thanks for the changes. IMO, now it looks better. But I'm also not an expert here. We probably should wait for someone with greater expertise.

Copy link
Member

@ned-deily ned-deily left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR. But I don't think it is a good idea to attempt to provide an exhaustive list here. As already noted in the paragraph above in sysconfig.rst:

This is used mainly to distinguish platform-specific build directories and platform-specific built distributions

By implication, the exact values are not intended to be parsed. They are just configuration-unique values.

I would support changing the wording for macOS and to replace the macOS list with a few more modern examples, like:

Examples of macOS returned values:

- macosx-10.13-x86_64
- macosx-11-universal2
- macosx-15.5-arm64

Perhaps @zooba has an opinion on updates to the list of Windows values.

Also note that reST markup requires a blank line before the start of a list. The changes here disturb that. (See the doc preview)

@bedevere-app
Copy link

bedevere-app bot commented Jun 15, 2025

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

@bedevere-app

This comment was marked as duplicate.

@ivanbelenky ivanbelenky requested a review from ned-deily June 16, 2025 12:06
@ivanbelenky
Copy link
Author

Thanks @ned-deily

I have made the requested changes; please review again

@bedevere-app
Copy link

bedevere-app bot commented Jun 16, 2025

Thanks for making the requested changes!

@ned-deily: please review the changes made to this pull request.

Examples of returned values:
Returned values:

Examples of Linux returned values:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Repeating "returned values" doesn't look very nice, IMO.

- win-amd64 (64-bit Windows on AMD64, aka x86_64, Intel64, and EM64T)
- win-arm64 (64-bit Windows on ARM64, aka AArch64)
- win32 (all others - specifically, sys.platform is returned)
- win-arm32 (32-bit Windows on ARM)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it's better to have examples for each platform, and remove win-arm32 here.

Copy link
Author

@ivanbelenky ivanbelenky Jun 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you mean by examples for each platform here? you mean 1 example per architecture, and not adressing arm32? something like

Examples of Windows platforms:

- win-amd64 (64-bit Windows on AMD64, aka x86_64, Intel64, and EM64T)
- win-arm64 (64-bit Windows on ARM64, aka AArch64)

I feel like it can be repetitive as well to have a title preceding each OS: "Examples of {OS} platforms:", but at least is consistent. I have no preference between this or a general

Example of returned values:

Windows
...

linux
...

macOs
...

Copy link
Contributor

@efimov-mikhail efimov-mikhail Jun 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I mean "Examples of returned values" for each platform. And win-arm32 value seems to be little redundant here in list of examples. I suggest to revert Windows platform examples list. Examples on Linux and macOS on current PR state looks fine, IMO


- win-amd64 (64-bit Windows on AMD64, aka x86_64, Intel64, and EM64T)
- win-arm64 (64-bit Windows on ARM64, aka AArch64)
- win32 (all others - specifically, sys.platform is returned)

This comment was marked as duplicate.

- linux-i586
- linux-i686
- linux-alpha (?)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- linux-alpha (?)
- android-9-arm64_v8a

For other non-POSIX platforms, currently just returns 'sys.platform'.
- linux-i586
- linux-i686
- linux-alpha (?)
Copy link
Contributor

@efimov-mikhail efimov-mikhail Jun 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- linux-alpha (?)
- android-24-arm64_v8a

Copy link
Member

@mhsmith mhsmith Jun 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know you probably got the Android example from the unit test, but this isn't actually a possible value because Android didn't add 64-bit support until API level 21. Also, this could mislead the reader into thinking it's the user-visible Android version rather than the API level. Suggest android-24-arm64_v8a, which is the version we're compiling against for Python 3.14.

Copy link
Contributor

@efimov-mikhail efimov-mikhail Jun 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for catch! I've had a little feeling that something is wrong.

@@ -382,22 +382,24 @@ Other functions

Examples of returned values:

Linux
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Linux
POSIX based OS:

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

macOS is also POSIX-based, so this would be confusing. How about reordering it as follows:

  • macOS
  • Other POSIX platforms
  • Windows
  • Other non-POSIX platforms

Copy link
Contributor

@efimov-mikhail efimov-mikhail Jun 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

macOS is also POSIX-based, so this would be confusing

Of course, you're right.
Maybe this list would be better?

  • Windows
  • POSIX platfroms
  • Other non-POSIX platforms

And include just one line for macOS at the POSIX section (macosx-15.5-arm64) after linux-x86_64 line and before android-9-arm64_v8a line.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that would be reasonable.

Copy link
Author

@ivanbelenky ivanbelenky Jun 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mhsmith @efimov-mikhail thanks a lot for your suggestions and comments

As far as this conversation goes I understand that this is the desired

   Windows:

   - win-amd64 (64-bit Windows on AMD64, aka x86_64, Intel64, and EM64T)
   - win-arm64 (64-bit Windows on ARM64, aka AArch64)

   POSIX based OS:
   
   - linux-x86_64
   - macosx-15.5-arm64
   - android-9-arm64_v8a

   Other non-POSIX platforms
   ...

I don't understand what will be the best option under non POSIX OS ? Is it reasonable is to remove the section and just leave the last sentence "For other non-POSIX platforms, currently just returns :data:sys.platform."?

win-amd64 (64-bit Windows on AMD64 (aka x86_64, Intel64, EM64T, etc)
win-arm64 (64-bit Windows on ARM64 (aka AArch64)
win32 (all others - specifically, sys.platform is returned)
Linux
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Linux
POSIX based OS:

@efimov-mikhail
Copy link
Contributor

efimov-mikhail commented Jun 17, 2025

I've digged into code and observed some important platforms such as Android.
So, I suggest to replace Linux section with more general POSIX based OS.

Speaking about text organization I'm not exactly sure that subsection with colons under section with colon is the best way, but I don't like raw "Windows" / "macOS" text before platform list.

@@ -382,22 +382,24 @@ Other functions

Examples of returned values:

Linux
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

macOS is also POSIX-based, so this would be confusing. How about reordering it as follows:

  • macOS
  • Other POSIX platforms
  • Windows
  • Other non-POSIX platforms

- linux-i586
- linux-i686
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

linux-i586 and linux-i686 are both obsolete. linux-x86_64 would be a better example.

@ivanbelenky ivanbelenky force-pushed the add-macos-docs-get_platform branch from 1fbd476 to f159723 Compare June 20, 2025 05:51
@efimov-mikhail
Copy link
Contributor

Ivan, you don't have to force push something, all commits will be squashed into one at merging stage.

@efimov-mikhail
Copy link
Contributor

efimov-mikhail commented Jun 20, 2025

I've added some changes that I thought will be useful after all discussions.
Of course, we want such changes at Lib/sysconfig/__init__.py too.

ivanbelenky and others added 5 commits June 21, 2025 00:43
Co-authored-by: Mikhail Efimov <[email protected]>
Co-authored-by: Mikhail Efimov <[email protected]>
Copy link
Contributor

@efimov-mikhail efimov-mikhail left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@efimov-mikhail
Copy link
Contributor

CC @zooba @ned-deily

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants