Can't find 'socket'

onePythonUser · November 25, 2024, 1:43am

Can you run it from “IDLE” to compare.

One observation from the traceback:

You are importing names from the package library charset_normalizer into the module api and then importing that module into other modules. Can you instead try removing the middle man (i.e., api), and instead import directly from the charset_normalizer module package into the other modules (wherever you are currently importing the api module into).

For example, comment this line out:

from .api import from_bytes, from_fp, from_path, is_binary # comment this line out

and replace with:

from charset_normalizer import from_bytes, from_fp, from_path, is_binary

Technically should not make a difference, but just to verify.

jeff5 · November 26, 2024, 11:29am

The discussion has picked up on several things now that would be worth investigating, if they were in Arthur’s code, but unless I’ve misunderstood badly, they are part of requests. I don’t think that’s the place to look.

If import requests leads to that traceback, something is wrong with the environment or the installation of requests. We have seen maybe 4 tracebacks now, and in 3 of them the problem is that Python cannot fnd a DLL we all know ought to be there. It is odd that we didn’t see the same under IDLE.

arthur brogard:

just now downloaded 3.13 and installed it and ran command ‘python’:

Python 3.13.0 (tags/v3.13.0:60403a5, Oct  7 2024, 09:38:07) [MSC v.1941 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
warning: can't use pyrepl: DLL load failed while importing unicodedata: The specified module could not be found.

doesn’t look good to me.

@abrogard You’re quite right. Never mind requests and charset_normalizer or any code you wrote. If you can’t run Python and load the REPL, then Python is broken on your machine. And it seems to be something to do with loading DLLs.

PyREPL is new in 3.13, but it is supposed to work, even on Windows. The explanation of why it can’t on your machine is significant. Did you get a prompt >>> next, or did it just stop there?

This is not a corner of CPython I know well, but almost certainly we are here:

github.com

python/cpython/blob/0f77357905a82ae03e6ba6868e4d7b2feef4f656/Python/dynload_win.c#L284


      
          } else {
              /* For some reason a \r\n
                 is appended to the text */
              if (theLength >= 2 &&
                  theInfo[theLength-2] == '\r' &&
                  theInfo[theLength-1] == '\n') {
                  theLength -= 2;
                  theInfo[theLength] = '\0';
              }
              message = PyUnicode_FromFormat(
                  "DLL load failed while importing %s: ", shortname);
          
              PyUnicode_AppendAndDel(&message,
                  PyUnicode_FromWideChar(
                      theInfo,
                      theLength));
          }
          if (message != NULL) {
              PyObject *shortname_obj = PyUnicode_FromString(shortname);
              PyErr_SetImportError(message, shortname_obj, pathname);
              Py_XDECREF(shortname_obj);

and that’s because this system call failed:

github.com

python/cpython/blob/0f77357905a82ae03e6ba6868e4d7b2feef4f656/Python/dynload_win.c#L234


      
          
                  /* Don't display a message box when Python can't load a DLL */
                  old_mode = SetErrorMode(SEM_FAILCRITICALERRORS);
          #endif
          
                  /* bpo-36085: We use LoadLibraryEx with restricted search paths
                     to avoid DLL preloading attacks and enable use of the
                     AddDllDirectory function. We add SEARCH_DLL_LOAD_DIR to
                     ensure DLLs adjacent to the PYD are preferred. */
                  Py_BEGIN_ALLOW_THREADS
                  hDLL = LoadLibraryExW(wpathname, NULL,
                                        LOAD_LIBRARY_SEARCH_DEFAULT_DIRS |
                                        LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR);
                  Py_END_ALLOW_THREADS
                  PyMem_Free(wpathname);
          
          #ifdef MS_WINDOWS_DESKTOP
                  /* restore old error mode settings */
                  SetErrorMode(old_mode);
          #endif

I know, it’s a bit desperate to resort to the source code. I only do it to show that something is quite fundamentally wrong. It’s not to do with the syntax of an import statement. I think we are left with:

It’s looking in the wrong places.
It is looking in the right places but there is nothing there (or something invalid?).
It is looking in the right places, and the right thing is there, but something prevents it being read.

Let’s find out how bad this installation is, avoiding the REPL. Does this work (at the command prompt where you ran the command python):

PS vsj> python -V
Python 3.13.0

This should tell you where Python looks for things:

PS vsj> python -c"import sys;print(sys.path)"
['', 'C:\\Users\\Jeff\\AppData\\Local\\Programs\\Python\\Python313\\python313.zip', 'C:\\Users\\Jeff\\AppData\\Local\\Programs\\Python\\Python313\\DLLs', 'C:\\Users\\Jeff\\AppData\\Local\\Programs\\Python\\Python313\\Lib', 'C:\\Users\\Jeff\\AppData\\Local\\Programs\\Python\\Python313', 'C:\\Users\\Jeff\\AppData\\Local\\Programs\\Python\\Python313\\Lib\\site-packages']

This is a clean installation on my machine. Anything like yours? There is a directory called DLLs in the list. I see 43 items there, mostly .pyd files and some .dll. You?

If bits are missing, the installation went wrong. (Full disk? Security software?) If they’re there but don’t load e.g when you import _socket, that suggests something is interfering. (Security software?)

There is a path length limitation on Windows, which the installation invites you to disable. That could be a reason for not finding files you know are there.

Finally, you can run

PS vsj> python -m test

which is thorough, but takes a lunch break to run on my machine.