search

epics-base / p4p

Python bindings for the PVAccess network client and server.
BSD 3-Clause "New" or "Revised" License
27 stars 38 forks source link

Updated the P4P Client API document. #91

Closed KuktaeKim closed 2 years ago

KuktaeKim commented 2 years ago

In client.rst file,

There is a section that explains pvget and pvput in python using P4P as below:

Get and Put operations can be performed on single PVs or a list of PVs. ::

V = ctxt.get('pv:name') A, B = ctxt.get(['pv:1', 'pv:2']) ctxt.put('pv:name', 5) ctxt.put('pv:name', {'value': 5}) # equivalent to previous ctxt.put('pv:name', {'value.field_1': 5, 'value.field_2': 5}) # put to multiple fields

For the multiple fields, field_1.value -> value.field_1 and field_2.value -> value.field_2

mdavidsaver commented 2 years ago

Either field_1.value or value.field_1 could be encountered in different situations. eg. field_1.value in a QSRV group where field_1 is a group member with a value sub-field. Or value.field_1 may be one column in a NTTable.

The choice of example is largely arbitrary, and is intended to convey the idea that any (sub)field, or fields, can be set this way.

I'm inclined to keep the value.field_1 ordering as a hint that various .value are not special. A client may attempt to write any field. (Of course most servers don't accept writes to every field...)

KuktaeKim commented 2 years ago

That makes sense. Thank you for your explanation!