`site.py` hardcodes "python" instead of using `{implementation_lower}`

[ShaharNaveh]

Feature or enhancement

Proposal:

Currently in

cpython/Lib/site.py

Line 336 in d7b9ea5

return f'{userbase}/lib/python{version[0]}.{version[1]}{abi_thread}/site-packages'

the string "python" is hardcoded.

This creates issues for alternative Python implementations (e.g. PyPy, RustPython, etc.), which often rely on sys.implementation.name to determine the correct directory layout. By hardcoding "python", the code assumes CPython specifically, making it less portable.

Proposed change:

Change the offending line to use the {implementation_lower} instead as it is already used throughout the function

Has this already been discussed elsewhere?

No

Linked PRs

• gh-138614: site._get_path to respect non-default implementation name #138610

[picnixz]

First, note that the comment says:

# Same to sysconfig.get_path('purelib', os.name+'_user')

So we should be careful here. I don't use other implementations than CPython but wouldn't those other implementations actually offer their own site.py?
cc @FFY00

[picnixz]

Also, I fail to see the connection with:

which often rely on sys.implementation.name to determine the correct directory layout

If this relies on sys.implementation.name, should they actually care about what site contains? could you show us an actual real-world example (I really don't use other implementations so I never had such problems but I want to see an example of that)

[picnixz]

Oh I see that we indeed have an out-of-sync issue. In sysconfig:

# When modifying "purelib" scheme, update site._get_path() too.
...
        'posix_user': {
...
            'purelib': '{userbase}/lib/{implementation_lower}{py_version_short}{abi_thread}/site-packages',
...

So we're indeed having a mismatch here.