An automatic repair method for Python program API parameter compatibility issues

Abstract

The present invention discloses a method for automatically repairing Python program API parameter compatibility issues, comprising: extracting the calling APIs in the user project using an AST abstract syntax tree; obtaining the context information of each calling API using a code instrumentation method and running the user project, and serializing and saving the context information in a binary form into a Pickle file; obtaining the parameter definitions of the calling APIs in the new and old versions of the project, and establishing a mapping relationship between the new and old version API signatures; establishing a mapping relationship between the parameters of the two versions, and comprehensively evaluating the compatibility issues of the calling APIs between the two library versions by analyzing the type of each parameter, the type of parameter change, and the method of parameter transfer; locating APIs with destructive changes using an AST abstract syntax tree and repairing them, and finally automatically verifying the repair results. The present invention improves the accuracy of detecting and repairing compatibility issues such as API parameter deletion, addition, renaming, position change, and conversion of positional parameters to keyword parameters.

Description

Technical Field

[0001] The present invention belongs to the field of software defects and repairs in software engineering, and specifically relates to a method for detecting and repairing API parameter compatibility issues that arise during the evolution of third-party libraries in Python programs. Background Art

[0002] In current software development, Python third-party libraries have become crucial due to their widespread application in fields such as machine learning and scientific computing. However, the Application Programming Interfaces (APIs) of these libraries often change during their evolution, causing client applications that rely on specific versions to frequently crash due to compatibility issues. This forces users to manually fix their code to adapt to new library versions, a tedious and time-consuming process that is particularly difficult for large projects, affecting the stability and maintainability of projects based on these libraries. Furthermore, due to Python's flexible parameter passing mechanism, different parameter passing methods can also lead to compatibility differences.

[0003] Therefore, a tool that can automatically detect and fix APIs with destructive changes is urgently needed. Existing technologies primarily focus on API compatibility detection and analysis of library API change patterns. However, there are relatively few automatic fixes for compatibility issues caused by API parameters. Existing fixes often suffer from the following shortcomings: API compatibility analysis relies heavily on parameter definitions in the library source code, ignoring the impact of actual parameter delivery methods on compatibility; low automation levels, requiring the establishment of a database to assist in detection and repair; simple fixes that struggle to cope with flexible parameter delivery methods and diverse API call formats; and incomplete compatibility assessment standards. Summary of the Invention

[0004] Purpose of the invention: The present invention proposes a method for automatically repairing Python program API parameter compatibility problems, which can improve the accuracy of detecting and repairing API parameter compatibility problems.

[0005] Technical solution: The method for automatically repairing Python program API parameter compatibility issues described in the present invention specifically includes the following steps:

[0006] (1) Using the abstract syntax tree, extract the calling API of the third-party library specified in the project;

[0007] (2) Instrument the API calls obtained in step (1) using the code instrumentation method, and record the context information of each API call; then, by running the instrumented project, serialize the API context information in binary form and save it in a Pickle file;

[0008] (3) Using the calling API obtained in step (1), the dynamic method based on the Python inspect module and the static method based on the API full name calling path are used to obtain the parameter definitions of the calling API in the new and old versions of the project, and establish a mapping relationship between the new and old version API signatures;

[0009] (4) Using the parameter definitions obtained in step (3), establish the mapping relationship between the API parameters between the two library versions based on the three rules of parameter name, parameter position and parameter type. Then, evaluate the compatibility issues between the two versions of the API by analyzing each parameter type, parameter change type and parameter transmission method, and generate a parameter change type dictionary;

[0010] (5) For the incompatible APIs evaluated in step (4), they are located and repaired based on the AST abstract syntax tree, and finally a combination of dynamic and static methods is used to automatically verify the repaired results.

[0011] Furthermore, the specific operations of step (1) are:

[0012] First, for each code file in the user's project, it is parsed into an abstract syntax tree using Python's built-in ast module;

[0013] Then use the breadth-first search algorithm to search for all Assign nodes, Import nodes, and ImportFrom nodes in the tree, which represent assignment statements, import statements, and from import statements in the code respectively;

[0014] Then use the depth-first search algorithm to search by branch to find all the Call nodes, which represent the API call statements in the code;

[0015] Finally, by combining assignment statements, import statements, and from import statements, the full name calling path of each API is restored, and based on the full name calling path, it is determined which third-party library the called API belongs to.

[0016] Furthermore, the specific operation of step (2) is:

[0017] First, preprocess the code to reduce its impact on code instrumentation. Code preprocessing operations include unifying code indentation, determining instrumentation locations, processing parameter wrapping, and expanding list derivations and if-else expressions.

[0018] For each third-party library call API obtained in step (1), an assignment statement will be inserted in the previous line with the same indentation, and the context information that the call API depends on will be saved in the assignment statement;

[0019] Finally, by running the instrumented project code and using the Python third-party library dill, the context information of each API call is serialized and saved in a pickle file in binary form.

[0020] Furthermore, the implementation process of step (3) is as follows:

[0021] For the calling API obtained in step (1), first use the Python built-in inspect module and the context information of the calling API loaded from the Pickle file to dynamically obtain the parameter definition of the project calling API and establish a mapping relationship between the new and old version API signatures; if the dynamic method acquisition fails, use the static method based on the API full name calling path to obtain the parameter definition of the project calling API and establish a mapping relationship between the new and old version API signatures.

[0022] Furthermore, the static method based on the API full name calling path in step (3) is:

[0023] First, all defined APIs are extracted from the library source code. Then, based on the class to which the API belongs, the module to which the class belongs, and the package to which the module belongs, the actual path of each API in the source code is constructed in the form of "library name.package name.module name.class name.API name". Then, by parsing the import statements in init.py under each directory in turn, the path of the API in the source code is adjusted to be consistent with the calling path provided by the official documentation of the library API. Static matching is easily affected by APIs with the same name and multiple API overloads, which will produce multiple candidate API mapping pairs.

[0024] Furthermore, the process of establishing the mapping relationship between the API parameters of the two library versions in step (4) is as follows:

[0025] In the first round, the mapping relationship between parameters is determined by the consistency of parameter names. Once the mapping is determined, the compatibility is analyzed by comparing the string literals of the parameters. For positional parameters, both type changes and position changes are analyzed; for keyword parameters, only type changes are analyzed. After the first round of analysis, the mapped parameters are removed from the list.

[0026] In the second round, in order to determine whether there is a change from positional parameters to keyword parameters or keyword parameters to positional parameters, the consistency of parameter names is used to establish the mapping relationship between positional parameters and keyword parameters;

[0027] In the third round, for the remaining positional parameters whose mapping relationships are not yet determined, a mapping relationship is established by considering both type and position consistency. For each positional parameter in the starting version, if a parameter with the same position and type can be found in the target version, they are considered to correspond, and duplicate name analysis can be performed at this time. For the remaining keyword parameters whose mapping relationships are not yet determined, a mapping relationship is established by type consistency. For each keyword parameter in the starting version, if a parameter with the same type can be found in the target version, they are considered to correspond, and rename analysis can be performed.

[0028] After three rounds of screening, any parameter that still has no mapping found in the starting version parameter list is considered to be deleted in the target version; accordingly, the remaining unmapped parameters in the target version are considered to be newly added parameters; after the parameter change analysis is completed, a parameter change type dictionary is generated.

[0029] Furthermore, the process of evaluating the compatibility of the API between the two versions in step (4) is as follows:

[0030] f(P,E,M)=P∧E∧M (1)

[0031]

[0032] Among them, f(P,E,M) represents the compatibility of each parameter, P represents the type of parameter, and its value range is {p,k}, where p represents positional parameter and k represents keyword parameter; E represents the change type of parameter, and its value range is {Δ d ,Δ r ,Δ o ,Δ k ,Δ p ,Δ t}, Δ d Indicates parameter deletion, Δ r Indicates parameter renaming, Δ o Indicates that the order of parameter position is changed, Δ k Indicates that the parameter is changed from a positional parameter to a keyword parameter, Δ p Indicates that the parameter is changed from a keyword parameter to a position parameter, Δ t Indicates that the type of the parameter has undergone a destructive change; M indicates the parameter transfer method, and its value range is {↑ n ,↑ p ,↑ k},↑n Indicates not to transmit, ↑ p Indicates position transfer, ↑ k Indicates passing in keyword mode; C invoked-API Indicates the compatibility of the API between two versions, depending on the compatibility of each parameter.

[0033] Furthermore, the implementation process of step (5) is as follows:

[0034] For the incompatible APIs identified in step (4), first locate the API to be repaired using the DFS algorithm, and repair the API by inserting, deleting, and modifying tree nodes in the abstract syntax tree; for the multiple API mapping relationship candidate items generated in step (3), prioritize excluding compatible candidate items and attempt to repair incompatible candidate items;

[0035] For each repaired candidate, static formal verification and dynamic runtime verification are used to judge the repair result. Only when both verifications pass at the same time is the repair considered successful; then the correct repair operation is updated to the user code file; as long as one verification fails, other candidates will be tried. When all candidates fail after being tried, the repair is considered a failure.

[0036] Furthermore, the static formal verification is as follows: first, a full parameter mirror of the API use case is constructed for the repaired API, that is, parameter names are added to all parameters in the API call, and then compared with the API parameter definition of the target version. For parameters used with parameter names, it is required that after repair, the parameters corresponding to the names can be found in the parameter definition of the target version. For parameters used without parameter names, it is required that after repair, the parameters corresponding to the positions and parameter names can be found in the parameter definition of the target version, thereby ensuring the formal correctness of the API.

[0037] Furthermore, the dynamic operation verification is as follows: firstly, the Pickle file corresponding to the calling API is loaded into the memory to obtain the parameter value of the API, and then the API is separately run and verified in the virtual environment of the project.

[0038] Beneficial effects: Compared with the existing technology, the beneficial effects of the present invention are: By adopting a combination of dynamic and static methods, the present invention has for the first time realized a fully automated process from API extraction, code instrumentation, establishment of API mapping relationships, change analysis to repair and verification. It is specifically used to solve compatibility problems caused by parameter addition, deletion, renaming, position change, and conversion of positional parameters into keyword parameters. In addition, in judging the compatibility issues of calling APIs, the accuracy of detecting and repairing API parameter compatibility issues is improved by combining the changes in parameters at the library definition level and the actual transmission method of parameters. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] Figure 1 is a flow chart of the present invention;

[0040] Figure 2 It is the overall framework diagram of the present invention;

[0041] Figure 3 It is the parameter change analysis diagram;

[0042] Figure 4 The figure is used to verify the repair results. DETAILED DESCRIPTION

[0043] The present invention will be described in further detail below with reference to the accompanying drawings.

[0044] like Figure 1 As shown, the present invention proposes a method for automatically repairing Python program API parameter compatibility issues, such as Figure 2 As shown, it first accepts a configuration file as input, which needs to include the following content: user project, third-party library that needs to be upgraded, virtual environment of the current version of the project, and virtual environment of the project upgraded to the target version, etc. Next, each code file in the user project is regarded as a task to be processed and added to the task queue. Subsequently, a process pool is used to process these task requests at the same time. Each process will execute a complete set of subsequent detection and repair processes to handle each task. The output results are divided into two parts: the corrected code file and an analysis report. The report records in detail the calling form, calling location, coverage, parameter definition in the current version and target version, compatibility and repair results of each API in the project. The specific implementation steps are as follows:

[0045] Step 1: Use the abstract syntax tree to extract the calling API of the third-party library specified in the project.

[0046] First, use Python's built-in ast module to parse all code files in the project into AST trees. Then use the Breadth First Search (BFS) algorithm to search the abstract syntax tree layer by layer to find the Assign type nodes, Import type nodes, and ImportFrom type nodes. These nodes represent the assignment statements, import statements, and from import statements in the code, respectively.

[0047] Secondly, for API call statements in the code, a depth-first search (DFS) algorithm is used to perform a branch-by-branch search to identify all Call nodes, which represent API call statements in the code. This is primarily determined by the storage structure of the API calls in the AST. This is because when the API call form in the user code is complex, such as in "A(B(x)).C(y)", function C is called using the return value of function A, and function B is called as the parameter value of function A. These API calls are located on the same branch of the tree. During the search, the DFS algorithm can accurately identify the forward and backward call relationship between each API and other APIs.

[0048] Finally, by combining assignment statements, import statements, and from import statements, the full name calling path of each API is restored, and based on the full name calling path, it is determined which third-party library the called API belongs to.

[0049] Step 2: Use the code instrumentation method to instrument the API calls obtained in step 1, record the context information of each API call (such as the caller, parameter values, etc.), and then run the instrumented project to serialize the API context information in binary form in a Pickle file.

[0050] When instrumenting user code, the varying programming styles of different project developers can lead to inconsistent code statements. Therefore, we first preprocess the code to minimize its impact on instrumentation. Code preprocessing primarily involves standardizing code indentation, determining instrumentation locations, handling parameter wrapping, and expanding list comprehensions and if-else expressions.

[0051] For each third-party library call API obtained in step 1, an assignment statement will be inserted in the previous line with the same indentation, and the context information that the call API depends on will be saved in the assignment statement. Use the "expand -t 4 "$code.py">"$temp"&&mv "$temp" "$code.py"shell" command to uniformly replace the tabs in the code with 4 spaces to facilitate accurate calculation of the indentation of each instrumentation statement. When determining the instrumentation location, insert the instrumentation statement in the previous line of the specified third-party library call API with the same indentation to avoid the influence of the return statement. Then, by using the AST abstract syntax tree, the parameters passed by the line break are modified to the same line, and the list derivation and if-else expression statements in the code are expanded.

[0052] Finally, by running the instrumented project code in the virtual environment of the project's starting version and using the Python third-party library dill, the context information of each API call is serialized and saved in a pickle file in binary form.

[0053] Step 3: Using the API call obtained in Step 1, obtain the signatures (parameter definitions) of the project's API calls in the new and old versions through dynamic methods based on the Python inspect module and static methods based on the API full name call path, and establish a mapping relationship between the new and old version API signatures.

[0054] First, we use Python's built-in inspect module and the contextual information of the API call loaded from the pickle file to dynamically obtain the signature (parameter definition) of the project's API call and establish a mapping relationship between the old and new API signatures. If the dynamic method fails, we use a static method based on the API full name call path to obtain the signature (parameter definition) of the project's API call and establish a mapping relationship between the old and new API signatures.

[0055] In the static method, all defined APIs are first extracted from the library source code, and then the real path of each API in the source code is constructed based on the class to which the API belongs, the module to which the class belongs, and the package to which the module belongs. The format is "library name.package name.module name.class name.AP name". However, in actual software development, library developers often use the import mechanism and init.py files to shorten the API path provided to users for calling. This, to a certain extent, causes the real path of the API in the source code to be inconsistent with the path provided by the library developer to the user for calling. Therefore, in order to improve the accuracy of static matching, this method parses the import statements in init.py under each directory in turn, thereby adjusting the path of the API in the source code to be consistent with the calling path provided by the official documentation of the library API. However, since static matching is easily affected by APIs with the same name and multiple overloads of APIs, multiple candidate API mapping pairs may be generated.

[0056] Step 4: If Figure 3 As shown in the figure, using the parameter definition obtained in step 3, the parameters in the API definition are first split into positional parameters and keyword parameters using the "*" sign. Then, based on the three rules of parameter name, parameter position, and parameter type, the mapping relationship between the API parameters of the two library versions is established. Then, by analyzing each parameter type, parameter change type, and parameter transmission method, the compatibility issues between the two versions of the API are evaluated, and a parameter change type dictionary is generated.

[0057] The establishment of the mapping relationship is divided into the following three rounds:

[0058] In the first round, parameter mappings are prioritized by checking parameter name consistency. Once the mappings are determined, compatibility is analyzed by comparing the parameter string literals. Positional parameters are analyzed for both type and position changes; keyword parameters, since their use is independent of position, are analyzed only for type changes. After the first round of analysis, mapped parameters are removed from the list to avoid interfering with subsequent mappings.

[0059] In the second round, in order to determine whether there is a change from positional parameters to keyword parameters or keyword parameters to positional parameters, the consistency of parameter names is used to establish the mapping relationship between positional parameters and keyword parameters.

[0060] In the third round, for the remaining positional parameters with undetermined mapping relationships, a mapping relationship is established by considering both type and position consistency. For each positional parameter in the starting version, if a parameter with the same position and type can be found in the target version, they are considered to correspond, and duplicate name analysis can be performed at this time. For the remaining keyword parameters with undetermined mapping relationships, a mapping relationship is established by type consistency. For each keyword parameter in the starting version, if a parameter with the same type can be found in the target version, they are considered to correspond, and rename analysis can be performed at this time.

[0061] After these three rounds of screening, any parameters that still have no mapping in the starting version's parameter list are considered deleted in the target version. Accordingly, any remaining unmapped parameters in the target version are considered newly added. After parameter change analysis is complete, a parameter change dictionary is generated for subsequent remediation operations.

[0062] Finally, we comprehensively evaluate the API compatibility between the two versions by analyzing the parameter type, parameter change type, and parameter transmission method. The parameter compatibility evaluation formula is as follows:

[0063] f(P,E,M)=P∧E∧M (1)

[0064]

[0065] In formula (1), f(P, E, M) represents the compatibility of each parameter, P represents the type of parameter, and its value range is {p, k}, where p represents positional parameter and k represents keyword parameter; E represents the change type of parameter, and its value range is {Δ d ,Δ r ,Δ o ,Δ k ,Δ p ,Δ t}, Δ dIndicates parameter deletion, Δ r Indicates parameter renaming, Δ o Indicates that the order of parameter position is changed, Δ k Indicates that the parameter is changed from a positional parameter to a keyword parameter, Δ p Indicates that the parameter has changed from a keyword parameter to a positional parameter, Δ t Indicates that the type of the parameter has undergone a destructive change; M indicates the parameter transfer method, and its value range is {↑ n ,↑ p ,↑ k},↑ n Indicates not to transmit, ↑ p Indicates position transfer, ↑ k Indicates that it is passed in keyword mode. In formula (2), C invoked-API Indicates the compatibility of the API between two versions, which depends on the compatibility of each parameter. Table 1 shows the compatibility of positional parameters and keyword parameters under different change types and transmission methods.

[0066] Table 1 Compatibility of positional parameters and keyword parameters under different change types and transmission methods

[0067]

[0068]

[0069] For example, p∧Δ o ∧↑ n , this formula means that a positional parameter has changed its position in theory (i.e., in the parameter definition in the library API source code), but the API does not use this changed parameter when it is actually called, so it has no effect on the compatibility of the API, so this combination is compatible. o ∧↑ p It also means that the position parameter has changed, but because it is actually passed by position when used, it will definitely be affected by the position change, so this starting version parameter call is incompatible in the target version.

[0070] p∧Δ o ∧↑ k It also indicates that the position of the position parameter has changed, but in actual use, it is passed as a keyword, that is, the parameter is passed with the parameter name. In Python syntax, if the position parameter is used with the parameter name, it does not need to be passed according to the fixed position of the parameter in the API definition, so it will not be affected by the position change, so it is compatible.

[0071] Step 5: For the incompatible APIs evaluated in step 4, locate and repair them based on the AST abstract syntax tree. Finally, use a combination of dynamic and static methods to automatically verify the repaired results.

[0072] First, the API to be repaired is located using the DFS algorithm. The API is repaired by inserting, deleting, or modifying tree nodes in the abstract syntax tree. If step 3 generates multiple API mapping pair candidates, compatible candidates are prioritized and incompatible candidates are repaired.

[0073] For each repaired candidate, such as Figure 4 As shown, static formal verification and dynamic runtime verification are used to judge the repair results. Only when both verifications pass is the repair considered successful, and the correct repair operation is then updated to the user code file. As long as one verification fails, other candidates will be tried. When all candidates fail after trying, the repair is considered a failure. In static formal verification, a full parameter mirror of the API use case is first constructed for the repaired API. That is, all parameters in the API are added with parameter names, and then compared with the API parameter definition of the target version. For parameters used with parameter names, the repair requires that the corresponding parameters with the names can be found in the parameter definition of the target version after the repair. For parameters used without parameter names, the repair requires that the corresponding parameters with both the position and parameter name can be found in the parameter definition of the target version after the repair, thereby ensuring the formal correctness of the API. In dynamic runtime verification, the pickle file corresponding to the called API is first loaded into memory to obtain the parameter values ​​of the API, and then the API is run and verified separately in the project's virtual environment.

[0074] The technical solutions provided by the embodiments of the present invention are described in detail above. Specific examples are used in this patent to illustrate the principles and implementation methods of the embodiments of the present invention. The above embodiments and features in the embodiments can be combined with each other unless there is a conflict. The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present invention shall be included in the scope of protection of the present invention.

Claims

1. A method for automatically repairing Python program API parameter compatibility issues, characterized in that: The following steps are involved: (1) Using the abstract syntax tree, extract the calling API of the third-party library specified in the project; (2) Instrument the API calls obtained in step (1) using the code instrumentation method, and record the context information of each API call; then, by running the instrumented project, serialize the API context information in binary form and save it in a Pickle file; (3) Using the calling API obtained in step (1), the dynamic method based on the Python inspect module and the static method based on the API full name calling path are used to obtain the parameter definitions of the calling API in the new and old versions of the project, and establish a mapping relationship between the new and old version API signatures; (4) Using the parameter definitions obtained in step (3), establish the mapping relationship between the API parameters between the two library versions based on the three rules of parameter name, parameter position and parameter type. Then, evaluate the compatibility issues between the two versions of the API by analyzing each parameter type, parameter change type and parameter transmission method, and generate a parameter change type dictionary; (5) For the incompatible APIs evaluated in step (4), they are located and repaired based on the AST abstract syntax tree, and finally a combination of dynamic and static methods is used to automatically verify the repaired results.

2. A method for automatically repairing Python program API parameter compatibility problems according to claim 1, characterized in that: The specific operations of step (1) are: First, for each code file in the user's project, it is parsed into an abstract syntax tree using Python's built-in ast module; Then use the breadth-first search algorithm to search for all Assign nodes, Import nodes, and ImportFrom nodes in the tree, which represent assignment statements, import statements, and from import statements in the code respectively; Then use the depth-first search algorithm to search by branch to find all the Call nodes, which represent the API call statements in the code; Finally, by combining assignment statements, import statements, and from import statements, the full name calling path of each API is restored, and based on the full name calling path, it is determined which third-party library the called API belongs to.

3. A Python program API parameter compatibility problem automatic repair method according to claim 1, characterized in that: The specific operations of step (2) are: First, preprocess the code to reduce its impact on code instrumentation. Code preprocessing operations include unifying code indentation, determining instrumentation locations, processing parameter wrapping, and expanding list derivations and if-else expressions. For each third-party library call API obtained in step (1), an assignment statement will be inserted in the previous line with the same indentation, and the context information that the call API depends on will be saved in the assignment statement; Finally, by running the instrumented project code and using the Python third-party library dill, the context information of each API call is serialized and saved in a pickle file in binary form.

4. A method for automatically repairing Python program API parameter compatibility problems according to claim 1, characterized in that: The implementation process of step (3) is as follows: For the calling API obtained in step (1), we first use the built-in inspect module of Python and the context information of the calling API loaded from the Pickle file to dynamically obtain the parameter definition of the project calling API and establish the mapping relationship between the new and old version API signatures; If the dynamic method fails to obtain the data, a static method based on the API full name calling path is used to obtain the parameter definition of the project calling API and establish a mapping relationship between the new and old version API signatures.

5. The method for automatically repairing Python program API parameter compatibility problems according to claim 1, characterized in that: The static method based on the API full name calling path in step (3) is: First, all defined APIs are extracted from the library source code. Then, based on the class to which the API belongs, the module to which the class belongs, and the package to which the module belongs, the actual path of each API in the source code is constructed in the form of "library name.package name.module name.class name.API name". Then, by parsing the import statements in init.py under each directory layer in turn, the API path in the source code is adjusted to be consistent with the calling path provided by the official documentation of the library API. Static matching is easily affected by APIs with the same name and multiple API overloads, which will generate multiple candidate API mapping pairs.

6. A method for automatically repairing Python program API parameter compatibility problems according to claim 1, characterized in that: The process of establishing the mapping relationship between the two library versions of the API parameters in step (4) is as follows: In the first round, the mapping relationship between parameters is determined by the consistency of parameter names. Once the mapping is determined, the compatibility is analyzed by comparing the string literals of the parameters. For positional parameters, both type changes and position changes are analyzed; for keyword parameters, only type changes are analyzed. After the first round of analysis, the mapped parameters are removed from the list. In the second round, in order to determine whether there is a change from positional parameters to keyword parameters or keyword parameters to positional parameters, the consistency of parameter names is used to establish the mapping relationship between positional parameters and keyword parameters; In the third round, for the remaining positional parameters whose mapping relationships are not yet determined, a mapping relationship is established by considering both type and position consistency. For each positional parameter in the starting version, if a parameter with the same position and type can be found in the target version, they are considered to correspond, and duplicate name analysis can be performed at this time. For the remaining keyword parameters whose mapping relationships are not yet determined, a mapping relationship is established by type consistency. For each keyword parameter in the starting version, if a parameter with the same type can be found in the target version, they are considered to correspond, and rename analysis can be performed. After three rounds of screening, any parameter that still has no mapping found in the starting version parameter list is considered to be deleted in the target version; accordingly, the remaining unmapped parameters in the target version are considered to be newly added parameters; after the parameter change analysis is completed, a parameter change type dictionary is generated.

7. A method for automatically repairing Python program API parameter compatibility problems according to claim 1, characterized in that: The process of evaluating the compatibility of the API between the two versions in step (4) is as follows: f(P, E, M) = P∧E∧M (1) Among them, f(P, E, M) represents the compatibility of each parameter, P represents the type of parameter, and its value range is {p, k}, where p represents positional parameter and k represents keyword parameter; E represents the change type of parameter, and its value range is {Δ d , Δ r , Δ o , Δ k , Δ p , Δ t }, Δ d Indicates parameter deletion, Δ r Indicates parameter renaming, Δ o Indicates that the order of parameter position is changed, Δ k Indicates that the parameter is changed from a positional parameter to a keyword parameter, Δ p Indicates that the parameter is changed from a keyword parameter to a position parameter, Δ t Indicates that the type of the parameter has undergone a destructive change; M indicates the parameter transfer method, and its value range is {↑ n ,↑ p ,↑ k },↑ n Indicates not to transmit, ↑ p Indicates position transfer, ↑ k Indicates passing in keyword mode; C invoked-API Indicates the compatibility of the API between two versions, depending on the compatibility of each parameter.

8. A method for automatically repairing Python program API parameter compatibility problems according to claim 1, characterized in that: The implementation process of step (5) is as follows: For the incompatible APIs identified in step (4), first locate the API to be repaired using the DFS algorithm, and repair the API by inserting, deleting, and modifying tree nodes in the abstract syntax tree; for the multiple API mapping relationship candidate items generated in step (3), prioritize excluding compatible candidate items and attempt to repair incompatible candidate items; For each repaired candidate, static formal verification and dynamic runtime verification are used to judge the repair result. Only when both verifications pass at the same time is the repair considered successful; then the correct repair operation is updated to the user code file; as long as one verification fails, other candidates will be tried. When all candidates fail after being tried, the repair is considered a failure.

9. A method for automatically repairing Python program API parameter compatibility problems according to claim 8, characterized in that: The static formal verification is as follows: first, a full parameter mirror of the API use case is constructed for the repaired API, that is, all parameters in the API call are added with parameter names, and then compared with the API parameter definition of the target version. For parameters used with parameter names, it is required that the parameters corresponding to the names can be found in the parameter definition of the target version after repair. For parameters used without parameter names, it is required that the parameters corresponding to the positions and parameter names can be found in the parameter definition of the target version after repair, so as to ensure the formal correctness of the API.

10. A method for automatically repairing Python program API parameter compatibility issues according to claim 8, characterized in that: The dynamic operation verification is as follows: first, the Pickle file corresponding to the calling API is loaded into the memory to obtain the parameter value of the API, and then the API is independently run and verified in the virtual environment of the project.

Images