Make the factory methods' interfaces consistent #304
Description
Versions
- Pymodbus: 1.5+ (Perhaps target 2.0 or beyond)
Pymodbus Specific
- Server: NA
- Client: All
Description
Pymodbus provides factory methods in its clients which present a relatively simpler interface. However, it is my (subjective) opinion that these methods are inconsistent and needlessly so.
Specifically, from client/common.py :
# instead of this
client = ModbusClient(...)
request = ReadCoilsRequest(1,10)
response = client.execute(request)
# now like this
client = ModbusClient(...)
response = client.read_coils(1, 10) Here, the current implementation allows the user to bypass the creation of the Request, and ask the ModbusClient for specific information, ie, a certain number of coils. However, for this interface to be symmetric, in the same spirit, it should also allow the user to bypass dealing with the Response object, instead returning exactly what the user asked for, ie :
# should be like this
client = ModbusClient(...)
coils = client.read_coils(1, 10)
assert(isinstance(coils, list)) Such an interface would not have been possible (and indeed, will not be possible as of this writing either) without unduly complicated hijinks until resolution of #298. Before the resolution of #298, the user would need the response object to be able to make sure that it isn't an ExceptionResponse or a ModbusIOException. Once pymobus raises these exceptions instead of returning them, such raising will rise up through to the user as any other Python exception and allow user code to catch and handle it in whatever way the user's application requires.
The immediate advantage will be to make the interface more intuitive to a user : Either prepare a request and get a response object back, or ask for something specific and let pymodbus handle both the request and response objects.
Such an interface, if created, will create the mechanism deemed missing during work for #293. Since the factory methods will no longer be expected to return ModbusResponse instances, with all the associated metadata and control data that entails, some of those factory methods can actually be multiple modbus transactions under the hood. For instance, it would be possible to write a consistent ModbusClient.read_device_identification() method which follows through with as many transactions as needed to retrieve the full set of identifiers and just returns the reassembled device identification dictionary. It will even be possible (though whether this is a good idea is a separate question) to hide from the user the limitation of the Modbus PDU, allowing user code to make read_registers() requests of more registers than a single Modbus PDU can handle, where the client would transparently create multiple requests and also reassemble the resulting responses into a single list of registers.