import requests!!!

[AaronZheng26]

step 1: Py_SetPath is deprecated, please add sys.path sys.path.append("/data/user/0/com.example.pythontest/files/Python64/") sys.path.append("/data/user/0/com.example.pythontest/files/Python64/lib-dynload")

step 2: fix collections.MutableMapping -> collections.abc.MutableMapping maybe need cross compile again.

[nverbeek]

You've mentioned two issues here, so I'll answer them separately:

1. You are correct, Py_SetPath is deprecated. We have not gotten around yet to updating our sample code to use the new functions. Being that this is just a sample, you can certainly make this change in your own project. We will make a note to come back here when we are able to update the sample app.
2. The requests library is included in the package as a convenience. This is a 3rd party package that we do not manage. The issue here is that older requests versions reference things that have moved in later versions of Python. If you want, in your project, you can update the PythonXX.zip files to include a different version of requests that does not suffer from this issue. Alternatively, you can easily get over this in your own Python code. Prior to importing requests, you can simply put code like this:

import sys
if sys.version_info.major == 3 and sys.version_info.minor >= 10:
    import collections
    from collections import abc
    collections.MutableMapping = abc.MutableMapping
    collections.Mapping = abc.Mapping
    collections.Callable = abc.Callable

import requests
# rest of your code

The above code effectively replaces the collections portions at runtime to function on later versions of Python.

[GRRedWings]

Nate's thanks for the quick response on this. I have updated the sample app to clean up the deprecated warnings. I have also removed requests from the zip files. While requests is useful, it really should not be included in the sample application as it is not used. As shown here, it can be confusing to think that it might be part of the python build, which it is now.

Also removing requests, allows any developer using this project to pick their own favorite http library without the potential conflict of this one.

[AaronZheng26]

the first issue fixed

1. init python in Java_com_example_pythontest_PythonThread_initPython

// Tell Python our path PyStatus status; PyConfig config; PyConfig_InitPythonConfig(&config); config.isolated = 1; config.module_search_paths_set = 1; auto lRootPath = lPassedPath.substr(0, lPassedPath.find_last_of('/')); status = PyWideStringList_Append(&config.module_search_paths, lRootPath.c_str()); if (PyStatus_Exception(status)) { goto done; } status = PyWideStringList_Append(&config.module_search_paths, lPassedPath.c_str()); if (PyStatus_Exception(status)) { goto done; } status = PyWideStringList_Append(&config.module_search_paths, (lPassedPath + LIB_DYNLOAD).c_str()); if (PyStatus_Exception(status)) { goto done; } // Initialize Python, we only want to do this once! status = Py_InitializeFromConfig(&config); done: PyConfig_Clear(&config); ALOGD("Leaving initPython"); return status.exitcode;

2. fix PythonProcessing::loadFile

// PythonProcessing::loadFile(std::string &aFileName) if (lFilePos != std::string::npos) { lRawFileName = aFileName.substr(lFilePos + 1, aFileName.length()); } else { lRawFileName = aFileName; }

[GRRedWings]

Great timing on your changes. The merged code has very similar changes to what you have posted above.