I built python 3.13.1 from source using MSVC , using call build.bat -e -v -p x64 , had no issues in building . After building it I installed numpy 2.1.0 whl from pypi. then I tried using this python over nfs on remote host I am getting numpy import error -
ImportError: DLL load failed while importing _multiarray_umath: The parameter is incorrect.
same set of steps works for me with python3.12.6. seems something is changed in 3.13.1 when trying import over nfs.
could someone please help As I am unable to figure out.
raised issue with numpy dev as well numpy/numpy#28216 , but it seems issue with the way how new python is working. any help is appreciated.
Looks like it started emitting this error in 500b0f4, but right before that it simply crashed when trying to import numpy. So, I'm not sure if it's only Python which is to blame. I'm going to try again with an earlier numpy version.
I would just note that getpath_realpath only attempts to strip \\?\ from drive paths and doesn't handle \\?\UNC at all:
Yeah, I suspect this is probably it. It changed in #86179, which looks like it only landed in 3.13 but pretty early on. Clearly we don't have any tests for running from UNC mounts.
The only other workaround might be setting PYTHONEXECUTABLE to the full path to python.exe, but that may have adverse impact on virtual environments, and it might not even work.
Alternatively, copy Python onto the local machine and use PYTHONPATH to import modules from the network.
If you're building from source, you could add the extra check for \\?\UNC\ into getpath.c and handle it (and submit a PR, which will get it fixed in the next release if nobody else gets to it)
Activity
Ganeshkumhar1 commented on Jan 28, 2025
can this be reviewed please.
zooba commented on Jan 28, 2025
The actual numpy issue is numpy/numpy#28216
And the relevant information (missing from this report) seems to be:
@barneygale @nineteendo Does this ring a bell to either of you? Did we change something that would add \\?\UNC here? Or fail to remove it?
ChrisDenton commented on Jan 28, 2025
I would just note that getpath_realpath only attempts to strip \\?\ from drive paths and doesn't handle \\?\UNC at all:
cpython/Modules/getpath.c
Lines 544 to 554 in 180ee43
Whereas the realpath in ntpath handles both cases:
cpython/Lib/ntpath.py
Lines 745 to 754 in 180ee43
nineteendo commented on Jan 28, 2025
I don't recall changing UNC prefixes, but let me do a bisect first.
nineteendo commented on Jan 28, 2025
nineteendo commented on Jan 29, 2025
Looks like it started emitting this error in 500b0f4, but right before that it simply crashed when trying to import numpy. So, I'm not sure if it's only Python which is to blame. I'm going to try again with an earlier numpy version.
UPDATE: the error doesn't occur on numpy 1.25.0.
Ganeshkumhar1 commented on Jan 29, 2025
@nineteendo did you try numpy 1.25.0 on python 3.13.1?
as per numpy dev numpy 2.1.0 is first version to support on python 3.13.1
numpy/numpy#28207 (comment)
nineteendo commented on Jan 29, 2025
I only checked if the import succeeded. I tried again by disabling from collections.abc import Buffer, it now starts crashing in de64e75.
zooba commented on Jan 29, 2025
Yeah, I suspect this is probably it. It changed in #86179, which looks like it only landed in 3.13 but pretty early on. Clearly we don't have any tests for running from UNC mounts.
Ganeshkumhar1 commented on Jan 31, 2025
@zooba @nineteendo , Is there any workaround I can use to fix this issue without setting PYTHONHOME.
zooba commented on Jan 31, 2025
The only other workaround might be setting PYTHONEXECUTABLE to the full path to python.exe, but that may have adverse impact on virtual environments, and it might not even work.
Alternatively, copy Python onto the local machine and use PYTHONPATH to import modules from the network.
If you're building from source, you could add the extra check for \\?\UNC\ into getpath.c and handle it (and submit a PR, which will get it fixed in the next release if nobody else gets to it)