GeezerVison

🏁 Script executed:

# First, let's examine the sysconfig.rs file to see its full context
wc -l crates/vm/src/stdlib/sysconfig.rs

Repository: RustPython/RustPython

Length of output: 186

🏁 Script executed:

# Check the complete sysconfig.rs file and its module definition
cat -n crates/vm/src/stdlib/sysconfig.rs

Repository: RustPython/RustPython

Length of output: 186

🏁 Script executed:

# Search for how sysconfig is registered/loaded and any platform guards
rg -n "sysconfig" crates/vm/src/stdlib/ --type rust -B 3 -A 3

Repository: RustPython/RustPython

Length of output: 186

🏁 Script executed:

# Check for platform-specific gates on sysconfig module
rg -n "#\[cfg" crates/vm/src/stdlib/sysconfig.rs

Repository: RustPython/RustPython

Length of output: 186

🏁 Script executed:

# Search for EXT_SUFFIX usage across the codebase
rg -n "EXT_SUFFIX" crates/vm/src/ --type rust -B 2 -A 2

Repository: RustPython/RustPython

Length of output: 186

🌐 Web query:

CPython sysconfig EXT_SUFFIX platform specific Windows Unix macOS

💡 Result:

Short summary — what EXT_SUFFIX is and platform differences, and how to get it:

• EXT_SUFFIX is the filename suffix used for compiled Python extension modules (shared objects) for the current build — e.g. on POSIX you usually get .cpython-XY... .so (includes the SOABI), on Windows you get .pyd (often with a platform/ABI tag like .cp37-win_amd64.pyd when full suffix is available). [1][2]

• How CPython exposes it:

  • sysconfig.get_config_var('EXT_SUFFIX') — canonical API to query the extension suffix. On many Unix/macOS builds this returns the full tagged suffix (e.g. ".cpython-39m-darwin.so"). On some Windows builds it may return only ".pyd" (SOABI may be None). [2][5]
  • If you need the fuller Windows tag (e.g. ".cp37-win_amd64.pyd"), distutils.sysconfig.get_config_var('EXT_SUFFIX') historically returned the full value on Windows in some builds (useful as a fallback). Note: distutils is deprecated but still present in many Python versions; prefer sysconfig when possible. [0]

• Practical snippet:

  • import sysconfig; ext = sysconfig.get_config_var('EXT_SUFFIX')
  • fallback (Windows): import distutils.sysconfig; ext = distutils.sysconfig.get_config_var('EXT_SUFFIX') if ext is None or ext == '.pyd' else ext. [0][1]

References:

• Python sysconfig docs (describe get_config_var / get_platform / usage). [1][2]
• StackOverflow discussion showing Windows behavior and distutils fallback. [0]

Sources:
[0] StackOverflow — "Python generate SOABI/Extension Suffix (pep 3149) for Windows".
[1] Python docs — sysconfig (library documentation).
[2] Python docs — Configure/using Python (notes on platform/config).

🌐 Web query:

RustPython sysconfig module EXT_SUFFIX implementation

💡 Result:

Do you want (a) the RustPython source location that implements sysconfig/EXT_SUFFIX, (b) an explanation of how EXT_SUFFIX should behave (CPython behaviour), or (c) help implementing/fixing EXT_SUFFIX in RustPython?

🌐 Web query:

CPython fileutils.c _Py_attribute_data_to_stat Windows implementation Python 3.12

💡 Result:

Summary — what CPython 3.12 does on Windows in fileutils.c for _Py_attribute_data_to_stat

• Purpose: convert Windows file attribute structures into CPython's internal struct _Py_stat_struct so os.stat()/lstat()/DirEntry.stat() etc. can return Python stat results on Windows. [1], [2].

• Inputs (Windows): BY_HANDLE_FILE_INFORMATION *info, ULONG reparse_tag, FILE_BASIC_INFO *basic_info, FILE_ID_INFO *id_info. Output: fills struct _Py_stat_struct *result. [1], [2].

• Key fields set:

  • st_mode: derived from Windows FILE_ATTRIBUTE_* via attributes_to_mode() (sets S_IFDIR/S_IFREG and permission bits). [2]
  • st_size: combined from info->nFileSizeHigh and info->nFileSizeLow into a 64-bit size. [2]
  • st_ino: taken from FileIdInfo (FILE_ID_INFO / FILE_ID_128) when available; otherwise from fileInfo.nFileIndexHigh/nFileIndexLow (handled as 64-bit inode). (CPython has historically fixed signed/unsigned inode casting issues.) [2], [3]
  • st_nlink: set from BY_HANDLE_FILE_INFORMATION (nNumberOfLinks) when available (or default 1). [2]
  • times (atime/mtime/ctime / st_atime_ns etc.): converted from FILE_BASIC_INFO / FILETIME to time_t / nanoseconds using internal helpers (e.g. _Py_time_t_to_FILE_TIME / conversions). [1], [2]
  • Windows-specific fields: st_file_attributes (dwFileAttributes) and st_reparse_tag get populated when supported. [1], [2]

• Behavior notes:

  • If FileIdInfo is not available, CPython falls back to file index fields. The implementation handles 64-bit sizes/inos to avoid overflow issues. [2], [3]
  • The function is declared in Modules/posixmodule.c and implemented in Python/fileutils.c on Windows builds. [1], [2]

Sources

• declaration and usage in Modules/posixmodule.c (Windows-specific stat helpers). [1]
• implementation of _Py_attribute_data_to_stat in Python/fileutils.c (code that sets st_mode, st_size, st_ino, times, st_file_attributes, st_reparse_tag, etc.). [2]
• Python issue discussion about inode signed/unsigned handling (relevant to how st_ino is handled). [3]

References
[1] Modules/posixmodule.c — CPython (Windows declarations/usages).
[2] Python/fileutils.c — implementation of _Py_attribute_data_to_stat.
[3] bpo-29619 discussion / commit about st_ino unsigned conversion.

🏁 Script executed:

# First, let's examine the RustPython implementation more closely
fd -t f "windows.rs" --path "*/vm/src/*" | head -5

Repository: RustPython/RustPython

Length of output: 186

🌐 Web query:

CPython Python/fileutils.c st_ctime st_birthtime _Py_attribute_data_to_stat 3.12 source code

💡 Result:

Do you want the full source of fileutils.c (Windows/PC or the POSIX one), or just the implementation of _Py_attribute_data_to_stat and related st_ctime / st_birthtime handling from CPython 3.12? I can fetch and paste the exact code with file/line citations.

🌐 Web query:

CPython os.stat_result fields Windows FILE_ATTRIBUTE handling 3.12

💡 Result:

Short summary (CPython 3.12)

• os.stat_result on Windows includes these Windows-specific members:
  • st_file_attributes — the raw dwFileAttributes (DWORD) from BY_HANDLE_FILE_INFORMATION. Use the FILE_ATTRIBUTE_* constants in the stat module to test bits. [1][2]
  • st_reparse_tag — present when FILE_ATTRIBUTE_REPARSE_POINT is set; contains the reparse tag (IO_REPARSE_TAG_*). [1]
• Cross‑platform/Unix-compatible members (st_mode, st_size, st_atime, st_mtime, etc.) remain present; when accessed as a tuple the first 10 entries follow the traditional order. [1]
• Platform differences/notes on Windows:
  • st_ino, st_dev and st_nlink are set to zero by the Windows implementation (use os.stat() for best available values). [1]
  • In Python 3.12 the st_ctime attribute is deprecated on Windows; the creation time is exposed as st_birthtime. st_ctime may be changed in future. [1]
• Use the stat module’s FILE_ATTRIBUTE_* constants (e.g. stat.FILE_ATTRIBUTE_ARCHIVE, FILE_ATTRIBUTE_REPARSE_POINT, FILE_ATTRIBUTE_HIDDEN, FILE_ATTRIBUTE_READONLY, etc.) to inspect st_file_attributes. [3]

Sources:

• os.stat_result and Windows-specific fields (Python 3.12 docs). [1]
• os.stat Windows notes (st_ino/st_dev/st_nlink zero; st_ctime deprecation). [1]
• stat module FILE_ATTRIBUTE_* constant list. [3]

References
[1] Python 3.12 os — Miscellaneous operating system interfaces documentation.
[2] (within same os docs) description of st_reparse_tag and st_file_attributes.
[3] Python stat module documentation listing FILE_ATTRIBUTE_* constants.

🌐 Web query:

CPython 3.12 Windows st_ino st_dev st_nlink zero why design decision fileutils.c

💡 Result:

Short answer: CPython on Windows uses whatever file metadata the platform/filesystem APIs provide, and many Windows filesystems or providers (network mounts, WebDAV/SharePoint, some UNC/shadow copies, FUSE-like drivers) do not expose POSIX-style device/inode/link-count values — so CPython populates st_ino, st_dev and st_nlink with 0 (dummy values) when the underlying API doesn't give meaningful numbers. This is a deliberate compatibility/portability choice in the Windows codepaths (and in the samefile/sameopenfile logic): treat zero-valued fields as “not available” and fall back to safer path/handle-based comparisons rather than trusting those fields. [1][2][3]

Why this design:

• Windows doesn’t guarantee POSIX inode/device semantics across all filesystems; some filesystems return no useful file index/device info, so returning 0 is the clean way to indicate “unavailable.” The docs note that some stat members are dummy on Windows and that st_ino may be up to 128 bits when available. [1]
• The Python Windows implementation then uses handle-based final-path comparisons (GetFinalPathNameByHandle and related logic) or other fallbacks when st_dev/st_ino are zero to avoid incorrect equality tests. The Python issue tracker discussion and patches show this behavior and the rationale (special-casing zero-valued fields and falling back to final NT path/handle checks). [2]
• This is a common cross-platform problem (e.g. C++ std::filesystem also had to special-case “no inode” Windows filesystems); libraries prefer explicit fallbacks over inventing fake inode/device values. [3]

References

• Python os.stat / Windows notes (3.12 docs): some stat members are dummy on Windows; st_ino changes noted. [1]
• Python issue discussion and implementation notes about samefile/sameopenfile and zero-valued st_dev/st_ino fallbacks (issue 33935 and related tickets). [2]
• Similar reasoning in other projects (example: libstdc++ handling of missing inode numbers on Windows). [3]