Python function dynamic management method, system and storage medium
By using a dual-hash registry and an execution attribute-aware asynchronous scheduling strategy, the problems of low service addressing efficiency and rigid calling methods in Python function management are solved, achieving efficient and flexible dynamic function management and improving system concurrency and resource utilization efficiency.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- GUANGDONG ESHORE TECH
- Filing Date
- 2026-02-09
- Publication Date
- 2026-05-29
Smart Images
Figure CN122111604A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computer technology, and in particular to a method, system, and storage medium for dynamic management of Python functions. Background Technology
[0002] With the widespread application of Python in microservice architecture, edge computing, big data processing and other scenarios, the system's need for dynamic management of Python functions is becoming increasingly urgent. Among these needs, core requirements such as high concurrency calls, cross-platform adaptation, flexible expansion and low resource consumption must be met simultaneously.
[0003] In related technologies, traditional function registration relies on a single hash table or list structure, which leads to frequent hash collisions and only supports a single access dimension. Service lookup efficiency degrades significantly with the increase in the number of functions. Function calls are mainly synchronous, and time-consuming operations can easily block the main thread, failing to fully utilize multi-core processor resources and resulting in insufficient throughput in high-concurrency scenarios. Function modules use a fully static loading method, consuming memory regardless of whether they are used, and dependencies need to be manually configured, which is prone to errors when changing them. Cross-platform adaptation requires hard-coded checks, resulting in high maintenance costs. These problems make it difficult to support the needs of large-scale, highly dynamic Python function management, and there is an urgent need for a technical solution that can decouple business logic from function management and improve calling efficiency and scalability. Summary of the Invention
[0004] The purpose of this invention is to provide a method, system, and storage medium for dynamic management of Python functions. Addressing the problems of low service addressing efficiency and rigid calling methods in existing Python function management systems, this invention achieves efficient service location by constructing a dual-hash registry of the main service and aliases. Furthermore, it dynamically matches asynchronous execution strategies such as coroutines, thread pools, or process pools based on function execution attributes, thereby improving system concurrency, resource utilization efficiency, and runtime flexibility.
[0005] To achieve the above objectives, the first aspect of the present invention provides a method for dynamic management of Python functions, the method comprising: Receive a function call service request, wherein the function call service request includes a target service identifier and a target function identifier; Based on the double hash registry, query the target service instance corresponding to the target service identifier in the function call business request; Based on the target function identifier, obtain the target function object of the target service instance; The execution attributes of the target function object are analyzed, and the target execution strategy is determined based on the execution attributes of the target function object; The target function object corresponding to the target service instance is executed according to the target execution strategy, and the execution result is returned.
[0006] Optionally, the step of querying the target service instance corresponding to the target service identifier in the function call business request based on the double hash registry includes: Determine whether the target service identifier contains an alias tag; If the target service identifier contains an alias tag, then query the alias hash registry of the double hash registry for the target service instance corresponding to the target service identifier; If the target service identifier does not contain or does not match the alias tag, then query the main service hash table of the double hash registry using the namespace as the key to find the corresponding target service instance; The dual hash registry includes the main service hash table and the alias hash table.
[0007] Optionally, before receiving the function call business request, the method further includes: Dynamically load the target service module, which contains service classes to be registered. Identify and instantiate service classes that conform to the preset base class criteria to obtain service instances to be registered; The service instance to be registered is registered to the main service hash table with a namespace, and the service instance configured with an alias is registered to the alias hash table with an alias.
[0008] Optionally, the dynamically loaded target service module includes: Listen for file change events in the preset plugin directory; When a new or updated Python source file is detected, it is loaded as the target service module.
[0009] Optionally, before registering the service instance to be registered to the double-hash registry, the method further includes: Parse the dependency information of the service instances to be registered to obtain a directed graph of service dependencies; Perform topological sorting on the directed graph of service dependencies to generate the service instantiation order; Each service class is instantiated sequentially according to the service instantiation order.
[0010] Optionally, parsing the execution attributes of the target function object and determining the target execution strategy based on the execution attributes includes: Determine whether the target function object is an asynchronous function; If the target function object is an asynchronous function, then the target execution strategy is determined to be an asynchronous coroutine scheduling strategy; If the target function object is not an asynchronous function, then the target execution strategy is determined to be either a process pool scheduling strategy or a thread pool scheduling strategy based on the configuration information of the target service instance.
[0011] Optionally, when the target execution strategy is an asynchronous coroutine scheduling strategy, the step of executing the target function object according to the target execution strategy and returning the execution result includes: A coroutine object is generated based on the target function object and the call parameters in the function call business request; Submit the coroutine object to the current event loop for scheduling; Return the object to be executed associated with the coroutine object as the execution result.
[0012] Optionally, when the target execution strategy is a thread pool scheduling strategy or a process pool scheduling strategy, the step of executing the target function object corresponding to the target service instance according to the target execution strategy and returning the execution result includes: The target function object and the call parameters in the function call business request are encapsulated into a task to be executed; Submit the task to be executed to the corresponding thread pool or process pool; Wait for the task to be executed to complete, and obtain the return value of the task to be executed as the result of the function call.
[0013] A second aspect of the present invention provides a Python function dynamic management system, the method comprising: The receiving module is used to receive function call business requests, the function call business requests including target service identifier and target function identifier; The query module is used to query the target service instance corresponding to the target service identifier in the function call business request based on the double hash registry; The acquisition module is used to acquire the target function object of the target service instance based on the target function identifier; A parsing module is used to parse the execution attributes of the target function object and determine the target execution strategy based on the execution attributes of the target function object; An execution module is used to execute the target function object corresponding to the target service instance according to the target execution strategy and return the execution result.
[0014] A third aspect of this application provides an electronic device, comprising: Processor; and A memory that stores executable code, which, when executed by the processor, causes the processor to perform the method described above.
[0015] This invention provides a method, system, and storage medium for dynamic management of Python functions. The method first receives a function call request containing a target service identifier and a target function identifier. Then, it quickly locates the target service instance based on a double-hash registry, extracts the target function object, and parses its execution attributes to determine a matching asynchronous execution strategy. Finally, based on this strategy, the function call is encapsulated into a coroutine task or a thread / process task for one-step scheduling and execution, and the result is returned. It is evident that this application, through the collaborative design of a double-hash registration mechanism and adaptive scheduling of execution strategies, shields the underlying execution differences, decouples business calls from asynchronous implementations, and achieves highly efficient, flexible, and scalable dynamic management of Python functions.
[0016] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description
[0017] The above and other objects, features and advantages of this application will become more apparent from the more detailed description of exemplary embodiments thereof in conjunction with the accompanying drawings, wherein the same reference numerals generally represent the same components in the exemplary embodiments thereof.
[0018] Figure 1 This is a flowchart illustrating a Python function dynamic management method according to an embodiment of this application.
[0019] Figure 2 This is a schematic diagram illustrating a function management structure based on a plug-in service directory and middleware components, as shown in an embodiment of this application.
[0020] Figure 3 This is a schematic diagram illustrating the structure of a Python function dynamic management system according to an embodiment of the present invention.
[0021] Figure 4 This is a schematic diagram of the structure of an electronic device according to an embodiment of the present invention. Detailed Implementation
[0022] Embodiments of this application will now be described in more detail with reference to the accompanying drawings. While embodiments of this application are shown in the drawings, it should be understood that this application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to make this application more thorough and complete, and to fully convey the scope of this application to those skilled in the art.
[0023] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.
[0024] It should be understood that although the terms "first," "second," "third," etc., may be used in this application to describe various information, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.
[0025] In related technologies, Python function call management often adopts static import and synchronous execution modes, or relies on a simple service registry center with a fixed thread pool for task distribution. The former, in microservice or plug-in architectures, requires hard-coding service paths; adding new functional modules necessitates restarting the main program or modifying the calling code, resulting in poor scalability. The latter, while introducing asynchronous mechanisms, has a relatively simple execution strategy and cannot dynamically select the optimal execution backend based on function characteristics, such as synchronous / asynchronous or CPU / I / O intensive, leading to resource waste or performance bottlenecks. Furthermore, service lookup relies on a single hash table or list traversal; as the service scales, hash collisions become frequent or lookup efficiency degrades, severely impacting response speed in high-concurrency scenarios. In addition, the strong coupling between business logic and the underlying execution method requires developers to explicitly handle details such as coroutine scheduling and thread pool submission, resulting in high development complexity and limited system throughput and flexibility. This application embodiment achieves efficient service addressing through a dual hash registration mechanism, and combines it with an execution attribute-aware asynchronous scheduling strategy. Without increasing software and hardware costs, it decouples business calls from the execution backend, improves system concurrency, resource utilization efficiency, and runtime flexibility, and solves the core technical challenges in the dynamic management of Python functions.
[0026] Please see Figure 1 , Figure 1This is a flowchart illustrating a dynamic Python function management method provided in this application embodiment. The dynamic Python function management method provided in this application embodiment can be applied to system scenarios requiring high concurrency, on-demand loading, and flexible scheduling of function services, such as microservice governance platforms, edge computing task engines, pluggable AI inference frameworks, and automated operation and maintenance systems. This method achieves an adaptive scheduling approach by dynamically parsing function attributes at runtime and matching the optimal execution strategy. The method specifically includes the following steps: S10, Receive function call business requests; In this embodiment, the upper-layer business system or external client can initiate function call business requests according to the actual application scenario. For example, after receiving a user login API request, the microservice gateway can call the function in the user authentication service; after the edge node collects sensor data, it can trigger the function in the data analysis plugin; after the operation and maintenance platform receives an alarm event, it can execute the function in the automated repair script.
[0027] The function call service request must contain the core identification information necessary to complete the function call, wherein the core identification information includes at least: the target service identifier and the target function identifier.
[0028] The target service identifier is used to locate the service instance to be invoked. It can be the fully qualified namespace of the service class or a pre-defined business-friendly alias. The target function identifier is used to specify the specific function to be executed in this service instance, which is usually a function name string.
[0029] The system receives the function call business request through a preset unified call entry point, and parses out the target service identifier and target function identifier from it, which serve as the basis for subsequent service location and function execution, ensuring the integrity and accuracy of the request information.
[0030] S20. Query the target service instance corresponding to the target service identifier based on the double hash registry; In this embodiment, the system maintains a global double-hash registry during runtime for efficient storage and retrieval of all registered service instances. The double-hash registry consists of a main service hash table and an alias hash table, which are mapped to the corresponding service instance objects using the service class's canonical namespace and user-defined aliases as keys, respectively.
[0031] Based on the target service identifier, the system queries the dual-hash registry. If the identifier is a preset alias, it matches in the alias hash table; otherwise, it is considered a canonical namespace and searched in the main service hash table. Through this dual-index structure, the system can accurately locate the target service instance within average time complexity, effectively avoiding the performance degradation problem of traditional single-table registration in large-scale service scenarios, and significantly improving service discovery efficiency.
[0032] S30. Obtain the target function object of the target service instance based on the target function identifier; After successfully obtaining the target service instance, the system extracts the corresponding target function object from the instance's public interface based on the target function identifier. This function object is a callable entity in Python, which can be a regular synchronous function, an asynchronous coroutine function, or a method bound to an instance.
[0033] The system obtains function objects through a secure reflection mechanism and verifies their callability to ensure the security and reliability of subsequent execution and prevent runtime exceptions caused by non-existent functions or insufficient permissions.
[0034] S40. Analyze the execution attributes of the target function object, and determine the target execution strategy based on the execution attributes; To achieve optimal resource utilization and maximize execution efficiency, the system can analyze the inherent execution characteristics of the target function object. In this embodiment, the execution attributes mainly refer to whether the function is an asynchronous coroutine function and the resource configuration preferences declared by its service instance. The system uses the inspect module of the Python standard library to determine whether the target function object is an asynchronous function. If so, the target execution strategy is determined to be an asynchronous coroutine scheduling strategy, that is, the function is handed over to the main event loop for concurrent execution in a non-blocking manner; if not, the system further reads the configuration metadata of the target service instance to determine whether the target execution strategy is a thread pool scheduling strategy or a process pool scheduling strategy.
[0035] This adaptive mechanism enables the system to automatically select the most suitable execution backend based on the function type and resource requirements, without requiring the caller to explicitly specify the scheduling method, thus achieving instant adaptation upon invocation.
[0036] S50. Execute the target function object corresponding to the target service instance according to the target execution strategy, and return the execution result.
[0037] In this embodiment, the system encapsulates function calls into schedulable task units according to the determined target execution strategy and submits them to the corresponding asynchronous execution backend to achieve one-step scheduling. That is, the caller only needs to initiate a request once, and the system automatically completes the entire process of task dispatch, execution and result return without having to worry about the details of the underlying concurrency model.
[0038] If the target execution strategy is an asynchronous coroutine scheduling strategy, the system will combine the target function object and the calling parameters to generate a coroutine object, submit it to the current event loop, and return a waitable Task object as the execution result; If the target execution strategy is a thread pool or process pool scheduling strategy, the system will encapsulate the function and parameters into an executable task, submit it to the corresponding execution pool, and synchronously wait for its completion before returning the final function call result.
[0039] Understandably, for any strategy, the system guarantees the consistency of call semantics and the reliability of results, thereby providing unified, efficient, and flexible dynamic function management capabilities in complex scenarios with high concurrency and mixed function calls of multiple types.
[0040] As can be seen, the embodiments of this application, through the collaborative design of dual hash registration and adaptive scheduling of execution strategies, shield the underlying execution differences, decouple business logic from asynchronous implementation details, and solve the core technical problems in the existing Python function management system, such as low service addressing efficiency, rigid calling methods, and high resource consumption. Without increasing the cost of software and hardware, it significantly improves the system's throughput, scalability, and runtime flexibility.
[0041] In some embodiments, the step of querying the target service instance corresponding to the target service identifier in the function call business request based on the double hash registry specifically includes: S201. Determine whether the target service identifier contains an alias tag; S202. If the target service identifier contains an alias tag, then query the alias hash registry of the double hash registry for the target service instance corresponding to the target service identifier. S203. If the target service identifier does not contain or does not match the alias tag, then query the main service hash table of the double hash registry with the namespace as the key to find the corresponding target service instance. The dual hash registry includes the main service hash table and the alias hash table.
[0042] In this embodiment, the system identifies whether the target service identifier is an alias by using preset rules. For example, all aliases can be identified by a specific prefix or suffix, or the alias mapping relationship can be explicitly declared through a configuration file. When a service identifier such as @user_auth is received, the system determines that it contains an alias tag, and then performs an O(1) lookup in the alias hash table with user_auth as the key to quickly locate the corresponding service instance.
[0043] If the target service identifier has no alias tag, or if it has a tag but is not found in the alias hash table, the system treats it as the fully qualified namespace of the service class and performs a lookup in the main service hash table. This namespace is typically composed of the module path and class name, and is globally unique to ensure accurate service location.
[0044] In this embodiment, the core purpose of employing a dual hash structure is to balance standardization and ease of use. The main service hash table ensures the uniqueness and traceability of service registration, suitable for automated toolchains or internal system calls; the alias hash table provides an access point for business developers to remember and use. Working together, the two avoid the collision degradation of a single hash table under high concurrency and solve the pain point of hard-coded long paths in traditional service discovery, significantly improving system maintainability and call efficiency.
[0045] In some embodiments, prior to receiving the function call business request, the method further includes: S301. Dynamically load the target service module, wherein the target service module contains service classes to be registered; S302. Identify and instantiate a service class that conforms to the preset base class standard to obtain a service instance to be registered; S303. Register the service instance to be registered to the main service hash table with a namespace, and register the service instance with the configured alias to the alias hash table with the alias.
[0046] In this embodiment, the system can automatically scan a specified directory during startup or runtime and load the Python source files therein as target service modules. Each module can define one or more service classes, and only classes that explicitly inherit from a preset abstract base class are considered legitimate service units. The system can perform compliance checks by inspecting bases, filtering out non-service or test classes to ensure registration security.
[0047] Subsequently, the system instantiates each compliant service class, generating service instances to be registered. The instantiation process supports dependency injection, such as passing a database connection pool through the constructor, but acyclic dependencies must be ensured.
[0048] Finally, the system extracts the fully qualified namespace of the service class as the primary key and registers it in the main service hash table. If the service declares an alias in the class decorator or configuration file, the system iterates through the alias list and registers the same instance under multiple keys in the alias hash table. This dual registration mechanism lays the foundation for efficient subsequent queries.
[0049] like Figure 2 As shown, Figure 2 This is a schematic diagram illustrating a function management structure based on a plug-in service directory and middleware components, as shown in an embodiment of this application.
[0050] In some embodiments, based on Figure 2 The plugin service directory and middleware component architecture shown enable dynamic management of Python functions. In practical applications, the specific process is as follows: Step 1: The service loading engine in the middleware monitors file change events in the preset plugin service directory in real time. In this embodiment, the plugin service directory is a system-specified service module storage path. The directory contains Python service files adapted to different operating systems, such as Zfs_linux.py and Zfs_freebsd.py, as well as other business service module files corresponding to "More Services...". The service loading engine continuously detects the addition, update, and deletion operations of files in this directory through the file system monitoring interface to ensure real-time awareness of service module changes.
[0051] When a new Zfs_linux.py file is detected or a Zfs_freebsd.py file is updated in the plugin service directory, the service loading engine loads the Python source file as the target service module. The service loading engine filters out non-Python source files (such as configuration files and log files) in the directory and only processes files with the .py extension. Through Python's built-in dynamic import mechanism, the files are loaded as recognizable service modules, providing a foundation for the subsequent identification and instantiation of service classes.
[0052] Step 2: The service dependency resolver in the middleware parses the dependency information of the service instances to be registered in the target service module to obtain a directed service dependency graph. Taking the Zfs_linux.py module as an example, the ZFSLinuxService service class defined inside it will declare dependencies through preset attributes, such as dependency configuration service and database connection service. After the service dependency resolver collects the dependency information, it constructs a directed graph with services as nodes and dependency relationships as edges to clearly sort out the dependency hierarchy between services.
[0053] The service dependency resolver performs topological sorting on the directed graph of service dependencies to generate the service instantiation order. For the directed graph of ZFSLinuxService's dependencies, the service dependency resolver eliminates circular dependencies through a topological sorting algorithm and determines the instantiation priority. For example, it instantiates the configuration service first and then instantiates ZFSLinuxService to avoid service loading failures due to incorrect dependency order.
[0054] In this embodiment, the service loading engine identifies service classes in the target service module that conform to the preset base class standard, and completes instantiation in the instantiation order to obtain service instances to be registered. The service loading engine filters out non-core classes such as test classes and abstract classes in the module, and only instantiates service classes that inherit from the system's preset base class to ensure that all registered service instances are legitimate business service units.
[0055] The plugin service registry in the middleware registers the service instance to be registered to the main service hash table with the namespace as the key. If a service class such as ZFSLinuxService is configured with an alias, the same service instance is registered to the alias hash table with the alias as the key, forming a double hash registry containing the main service hash table and the alias hash table. For example, if the namespace of ZFSLinuxService is zfs.linux and the configured alias is zfs_linux, the plugin service registry will store this instance in both the main service hash table (key: zfs.linux) and the alias hash table (key: zfs_linux) to support subsequent fast queries.
[0056] Step 3: The function fast caller in the middleware receives function call requests initiated from outside. The request contains the target service identifier (e.g., alias: zfs_linux) and the target function identifier (e.g., get_disk_usage). The function fast caller determines whether the target service identifier contains an alias tag and queries the alias hash table in the plugin service registry to find the ZFSLinuxService instance. If the identifier is a namespace (e.g., zfs.linux), it queries the corresponding instance from the main service hash table.
[0057] The function fast caller extracts the corresponding target function object from the ZFSLinuxService instance based on the target function identifier get_disk_usage. The function fast caller parses the execution attributes of the get_disk_usage function. If it is an asynchronous function, it determines the asynchronous coroutine scheduling strategy. If it is a synchronous function, it selects a process pool or thread pool scheduling strategy according to the configuration information of the ZFSLinuxService instance.
[0058] The function fast caller executes the target function according to the selected execution strategy: if the strategy is asynchronous coroutine, a coroutine object is generated and submitted to the event loop scheduler; if the strategy is process pool / thread pool, the function and parameters are encapsulated as a task and submitted to the corresponding pool for execution, and the execution result is finally returned to the caller.
[0059] This embodiment achieves unified management and dynamic updates of service modules through a plugin service directory. Combined with core components in the middleware, such as the service loading engine, service dependency resolver, plugin service registry, and function fast caller, it completes the entire process management from service loading and registration to function calling, enabling efficient and flexible scheduling of Python functions.
[0060] In some embodiments, the dynamically loaded target service module specifically includes: S401, Listen for file change events in the preset plugin directory; S402. When a new or updated Python source file is detected, it is loaded as the target service module.
[0061] In this embodiment, the system monitors the preset plugin directory in real time using a file system monitoring tool. When a creation or modification event of a .py file is detected, the system automatically triggers the module reload process.
[0062] Specifically, the system first calls the dynamic import or refresh of module objects to avoid restarting the main process; then it executes the service identification, instantiation, and registration process described in the above embodiment to achieve hot-swapping of plugins at runtime. This mechanism greatly improves the system's scalability and operational efficiency, allowing new features to be launched without downtime, and faulty plugins to be replaced online, meeting the stringent high availability requirements of modern cloud-native applications.
[0063] In some embodiments, prior to registering the service instance to be registered to the double-hash registry, the method further includes: S501. Parse the dependency information of the service instance to be registered to obtain the service dependency directed graph; S502. Perform topological sorting on the service dependency directed graph to generate the service instantiation order; S503. Instantiate each service class sequentially according to the service instantiation order.
[0064] In this embodiment, each service class can declare its dependencies through decorators or class attributes. The system can collect the dependency declarations of all services during the loading phase and construct a directed service dependency graph, where nodes are service classes and directed edges represent "A depends on B".
[0065] The system then performs a topological sorting algorithm on the directed graph to generate a linear sequence, ensuring that any service is instantiated after its dependencies. If a cycle exists in the graph (e.g., A depends on B, and B depends on A), a circular dependency exception is thrown to prevent invalid registration.
[0066] Ultimately, the system instantiates each service class strictly according to the topological order. For example, if UserService depends on DatabaseService, the DatabaseService instance is created first and its context is injected, then UserService is created. This mechanism fundamentally avoids runtime errors such as null pointer exceptions or uninitialized resources.
[0067] In some embodiments, parsing the execution attributes of the target function object and determining the target execution strategy based on the execution attributes specifically includes: S601. Determine whether the target function object is an asynchronous function; S602. If the target function object is an asynchronous function, then the target execution strategy is determined to be an asynchronous coroutine scheduling strategy; S603. If the target function object is not an asynchronous function, then based on the configuration information of the target service instance, determine the target execution strategy as a process pool scheduling strategy or a thread pool scheduling strategy.
[0068] In this embodiment, the system uses the Python standard library to precisely determine whether a function is defined by `async def`. If so, it adapts to the event loop model and should adopt an asynchronous coroutine scheduling strategy to fully leverage the advantages of I / O concurrency.
[0069] In applications, if a function is a regular synchronous function, the system further reads the configuration metadata of its associated service instance. For example, a service class can be annotated with `@execution_mode("process")` to indicate CPU-intensive operation, suitable for process pool scheduling strategies to utilize multiple cores; or `@execution_mode("thread")` to indicate I / O-intensive operation, suitable for thread pool scheduling strategies to avoid the Global Interpreter Lock (GIL). If not explicitly configured, a thread pool is used by default.
[0070] Understandably, the two-level decision-making mechanism described above enables fine-grained matching of execution strategies, asynchronous function event loops, and synchronous functions are diverted to the optimal execution pool according to resource characteristics, maximizing hardware utilization while shielding underlying differences, allowing developers to focus solely on business logic.
[0071] In some embodiments, when the target execution strategy is an asynchronous coroutine scheduling strategy, the step of executing the target function object according to the target execution strategy and returning the execution result specifically includes: S701. Generate a coroutine object based on the target function object and the call parameters in the function call business request; S702. Submit the coroutine object to the current event loop for scheduling; S703. Return the object to be executed associated with the coroutine object as the execution result.
[0072] In this embodiment, the system combines the target function object with the calling parameters to generate a coroutine object. This coroutine object itself cannot be run directly and must be managed by the event loop.
[0073] Subsequently, the system encapsulates the coroutine object into a Task object (i.e., an object to be executed) using either `asyncio.create_task(coro)` or `loop.create_task(coro)`, and submits it to the current event loop. A Task object can be a subclass of Future, representing an asynchronous operation that can be waited for.
[0074] Ultimately, the system can directly return the Task object as the execution result. The caller can obtain the final value by waiting for the task or registering a callback to handle the completion event. The entire process does not block the main thread, allowing multiple coroutines to execute concurrently, greatly improving throughput in I / O-intensive scenarios.
[0075] In some embodiments, when the target execution strategy is a thread pool scheduling strategy or a process pool scheduling strategy, the step of executing the target function object corresponding to the target service instance according to the target execution strategy and returning the execution result specifically includes: S801. Encapsulate the target function object and the call parameters in the function call business request into a task to be executed; S802. Submit the task to be executed to the corresponding thread pool or process pool; S803. Wait for the task to be executed to complete, and obtain the return value of the task to be executed as the result of the function call.
[0076] In this embodiment, the system packages the target function object and its calling parameters into an executable unit, which is then submitted to a pre-initialized thread pool or process pool, the specific choice depending on the corresponding determined strategy.
[0077] After submission, the system can call the task's `.result()` method or an equivalent interface to synchronously wait for execution to complete. This wait is interruptible, timeout-based, and safe blocking, not an indefinite suspension. Once the task completes, the system retrieves its return value or catches an exception and returns it to the caller as the final result of this function call.
[0078] This pattern is compatible with all synchronous functions and avoids the overhead of frequent creation and destruction by pooling and reusing thread / process resources. It is especially suitable for legacy code that cannot be converted to asynchronous or CPU-intensive computations, achieving seamless integration with asynchronous coroutine paths.
[0079] See Figure 3 , Figure 3 This is a schematic diagram illustrating the structure of a Python function dynamic management system according to an embodiment of this application, including: Receiving module 31, the receiving module is used to receive function call business requests, the function call business requests including target service identifier and target function identifier; Query module 32, the query module is used to query the target service instance corresponding to the target service identifier in the function call business request based on the double hash registry; Acquisition module 33, the acquisition module is used to acquire the target function object of the target service instance based on the target function identifier; Parsing module 34, the parsing module is used to parse the execution attributes of the target function object, and determine the target execution strategy based on the execution attributes of the target function object; Execution module 35 is used to execute the target function object corresponding to the target service instance according to the target execution strategy and return the execution result.
[0080] In some embodiments, querying the target service instance corresponding to the target service identifier in the function call business request based on the double hash registry includes: Determine whether the target service identifier contains an alias tag; If the target service identifier contains an alias tag, then query the alias hash registry of the double hash registry for the target service instance corresponding to the target service identifier; If the target service identifier does not contain or does not match the alias tag, then query the main service hash table of the double hash registry using the namespace as the key to find the corresponding target service instance; The dual hash registry includes the main service hash table and the alias hash table.
[0081] In some embodiments, prior to receiving the function call business request, the method further includes: Dynamically load the target service module, which contains service classes to be registered. Identify and instantiate service classes that conform to the preset base class criteria to obtain service instances to be registered; The service instance to be registered is registered to the main service hash table with a namespace, and the service instance configured with an alias is registered to the alias hash table with an alias.
[0082] In some embodiments, the dynamically loaded target service module includes: Listen for file change events in the preset plugin directory; When a new or updated Python source file is detected, it is loaded as the target service module.
[0083] In some embodiments, prior to registering the service instance to be registered to the double-hash registry, the method further includes: Parse the dependency information of the service instances to be registered to obtain a directed graph of service dependencies; Perform topological sorting on the directed graph of service dependencies to generate the service instantiation order; Each service class is instantiated sequentially according to the service instantiation order.
[0084] In some embodiments, parsing the execution attributes of the target function object and determining the target execution strategy based on the execution attributes includes: Determine whether the target function object is an asynchronous function; If the target function object is an asynchronous function, then the target execution strategy is determined to be an asynchronous coroutine scheduling strategy; If the target function object is not an asynchronous function, then the target execution strategy is determined to be either a process pool scheduling strategy or a thread pool scheduling strategy based on the configuration information of the target service instance.
[0085] In some embodiments, when the target execution strategy is an asynchronous coroutine scheduling strategy, the step of executing the target function object according to the target execution strategy and returning the execution result includes: A coroutine object is generated based on the target function object and the call parameters in the function call business request; Submit the coroutine object to the current event loop for scheduling; Return the object to be executed associated with the coroutine object as the execution result. In some embodiments, when the target execution strategy is a thread pool scheduling strategy or a process pool scheduling strategy, the step of executing the target function object corresponding to the target service instance according to the target execution strategy and returning the execution result includes: The target function object and the call parameters in the function call business request are encapsulated into a task to be executed; Submit the task to be executed to the corresponding thread pool or process pool; Wait for the task to be executed to complete, and obtain the return value of the task to be executed as the result of the function call.
[0086] See Figure 4 The electronic device 500 includes a memory 510 and a processor 520.
[0087] The processor 520 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.
[0088] Memory 510 may include various types of storage units, such as system memory, read-only memory (ROM), and permanent storage devices. ROM may store static data or instructions required by the processor 520 or other modules of the computer. Permanent storage devices may be read-write storage devices. Permanent storage devices may be non-volatile storage devices that retain stored instructions and data even when the computer is powered off. In some embodiments, permanent storage devices use mass storage devices (e.g., magnetic or optical disks, flash memory) as permanent storage devices. In other embodiments, permanent storage devices may be removable storage devices (e.g., floppy disks, optical drives). System memory may be a read-write storage device or a volatile read-write storage device, such as dynamic random access memory. System memory may store some or all of the instructions and data required by the processor during operation. Furthermore, memory 510 may include any combination of computer-readable storage media, including various types of semiconductor memory chips (e.g., DRAM, SRAM, SDRAM, flash memory, programmable read-only memory), and disks and / or optical disks may also be used. In some embodiments, memory 510 may include a removable storage device that is readable and / or writable, such as a laser disc (CD), a read-only digital multifunction optical disc (e.g., DVD-ROM, dual-layer DVD-ROM), a read-only Blu-ray disc, an ultra-high density optical disc, a flash memory card (e.g., SD card, mini SD card, Micro-SD card, etc.), a magnetic floppy disk, etc. Computer-readable storage media do not contain carrier waves or transient electronic signals transmitted wirelessly or via wired connections.
[0089] The memory 510 stores executable code, which, when processed by the processor 520, can cause the processor 520 to execute part or all of the methods described above.
[0090] Furthermore, the method according to this application can also be implemented as a computer program or computer program product, which includes computer program code instructions for performing some or all of the steps in the method described above.
[0091] Alternatively, this application may be implemented as a computer-readable storage medium (or a non-transitory machine-readable storage medium or a machine-readable storage medium) storing executable code (or computer program or computer instruction code) that, when executed by a processor of an electronic device (or server, etc.), causes the processor to perform part or all of the steps of the methods described above according to this application.
[0092] This application also provides a computer program product, which includes computer instructions that, when executed by a processor, implement the method described above.
[0093] The various embodiments of this application have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or improvement of the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.
Claims
1. A method for dynamic management of Python functions, characterized in that, The method includes: Receive a function call service request, wherein the function call service request includes a target service identifier and a target function identifier; Based on the double hash registry, query the target service instance corresponding to the target service identifier in the function call business request; Based on the target function identifier, obtain the target function object of the target service instance; The execution attributes of the target function object are analyzed, and the target execution strategy is determined based on the execution attributes of the target function object; The target function object corresponding to the target service instance is executed according to the target execution strategy, and the execution result is returned.
2. The method according to claim 1, characterized in that, The step of querying the target service instance corresponding to the target service identifier in the function call business request based on the double hash registry includes: Determine whether the target service identifier contains an alias tag; If the target service identifier contains an alias tag, then query the alias hash registry of the double hash registry for the target service instance corresponding to the target service identifier; If the target service identifier does not contain or does not match the alias tag, then query the main service hash table of the double hash registry using the namespace as the key to find the corresponding target service instance; The dual hash registry includes the main service hash table and the alias hash table.
3. The method according to claim 1, characterized in that, Before receiving the function call service request, the following is also included: Dynamically load the target service module, which contains service classes to be registered. Identify and instantiate service classes that conform to the preset base class criteria to obtain service instances to be registered; The service instance to be registered is registered to the main service hash table with a namespace, and the service instance configured with an alias is registered to the alias hash table with an alias.
4. The method according to claim 3, characterized in that, The dynamically loaded target service module includes: Listen for file change events in the preset plugin directory; When a new or updated Python source file is detected, it is loaded as the target service module.
5. The method according to claim 3, characterized in that, Before registering the service instance to be registered to the double-hash registry, the following is also included: Parse the dependency information of the service instances to be registered to obtain a directed graph of service dependencies; Perform topological sorting on the directed graph of service dependencies to generate the service instantiation order; Each service class is instantiated sequentially according to the service instantiation order.
6. The method according to claim 1, characterized in that, The step of parsing the execution attributes of the target function object and determining the target execution strategy based on the execution attributes includes: Determine whether the target function object is an asynchronous function; If the target function object is an asynchronous function, then the target execution strategy is determined to be an asynchronous coroutine scheduling strategy; If the target function object is not an asynchronous function, then the target execution strategy is determined to be either a process pool scheduling strategy or a thread pool scheduling strategy based on the configuration information of the target service instance.
7. The method according to claim 6, characterized in that, When the target execution strategy is an asynchronous coroutine scheduling strategy, the step of executing the target function object according to the target execution strategy and returning the execution result includes: A coroutine object is generated based on the target function object and the call parameters in the function call business request; Submit the coroutine object to the current event loop for scheduling; Return the object to be executed associated with the coroutine object as the execution result.
8. The method according to claim 6, characterized in that, When the target execution strategy is a thread pool scheduling strategy or a process pool scheduling strategy, the step of executing the target function object corresponding to the target service instance according to the target execution strategy and returning the execution result includes: The target function object and the call parameters in the function call business request are encapsulated into a task to be executed; Submit the task to be executed to the corresponding thread pool or process pool; Wait for the task to be executed to complete, and obtain the return value of the task to be executed as the result of the function call.
9. A Python function dynamic management system, characterized in that, The method includes: The receiving module is used to receive function call business requests, the function call business requests including target service identifier and target function identifier; The query module is used to query the target service instance corresponding to the target service identifier in the function call business request based on the double hash registry; The acquisition module is used to acquire the target function object of the target service instance based on the target function identifier; A parsing module is used to parse the execution attributes of the target function object and determine the target execution strategy based on the execution attributes of the target function object; An execution module is used to execute the target function object corresponding to the target service instance according to the target execution strategy and return the execution result.
10. A computer-readable storage medium having executable code stored thereon, which, when executed by a processor of an electronic device, causes the processor to perform the method as described in any one of claims 1-8.