Hello

[mvanriet]

Hello,

We are trying to make a similar library. We may opt to abandon our efforts and join this project instead, since a Google-backed repo will undoubtedly gain more traction. However, it is strange that it is put on github by a brand new user. So we wonder about its history and future :

• is this an active project, or just a dead project which is open-sourced because no-one is working on it any more ?
• how many contributers are there ?
• will there be more additions ?
• is there someone who will actively integrate pull requests ?

Best regards, Marc

[quatchi2010]

Dear Marc,

Thank you for your interest in py-lab-hal! We're excited to hear that you're considering using it.

I'm James, and I'm part of the team at Google working on this project. You're right, it's relatively new to GitHub, but it's definitely not a dead project. py-lab-hal was actually developed internally at Google over several years and we recently decided to open-source it to encourage broader collaboration and community involvement.

We are actively working on py-lab-hal and also reviews pull requests and plans future development. We welcome contributions and are excited to see how the community can help shape its future.

We encourage you to explore the project further and would be happy to answer any other questions you may have.

Best regards, James on behalf of py-lab-hal team

[mvanriet]

Hello James,

Thank you for the feedback, and great to hear it is a live project.

If I may, a question about the high-level API : there is a base class for every type of instrument with the most common interface functions, and it seems to be quite consistent between instrument types. However, it is quite limited, so it is probably developed using a no-nonsense approach and just implement what you need ?

In contrast, there are the IVI specifications, which are very elaborate and complex, but do have the advantage of having a broad and long-term view. The python-ivi library uses this API, but unfortunately this library is not maintained any more, and is also difficult to extend because it started in the Python 2.x era, which doesn't have the flexibility of Python 3.x, e.g. for dynamically creating classes.

Also, it is remarkable that you don't use properties anywhere to set and get values. E.g. mypsu.channel[0].voltage = 5 seems more Pythonic than mypsu.set_voltage(1,5)

Best regards, Marc

[quatchi2010]

Dear Marc,

Thank you for your thoughtful message and your interest in contributing to the design of py-lab-hal! We appreciate you taking the time to share your perspective on the API, particularly regarding the use of properties.

We are carefully considering how to how to evolve the API and abstraction layer in py-lab-hal, and your input on this is very valuable. We're always happy to hear about real-world use cases and how developers interact with the library, so please do continue to share your thoughts and experiences as you use py-lab-hal.

We had a full discussion within the team about your suggestion to use properties for channel access, like mypsu.channel[0].voltage = 5.

You're absolutely right that this approach feels more Pythonic and intuitive. However, we also want to maintain consistency and adhere to established style guidelines, such as the Google Python Style Guide.

Section 2.13.4 of the guide advises against using properties for simple attribute access without computation. In the case of basic voltage and current settings.

Reference For example, using a property to simply both get and set an internal attribute isn’t allowed: there is no computation occurring. Here the current is a value that is no need the computation. Therefore, this shows that it is not support to us using the property here.

Reference In comparison, using a property to control attribute access or to calculate a trivially derived value is allowed: the logic is simple and unsurprising. Here we are not control the attribute access (e.g read only) and there is no calculation is involued. Therefore, again his shows that it is not support to us using the property here.

We also consider the other channel usage case in the scope. The supply current and voltage here is a simple use case. However, channel settings in an oscilloscope are much more complicated. For example, setting up a trigger or measurement will require multiple parameters to do so. Therefore, maintaining a consistent API design across different instrument types is important to us.

That being said, we value your input and are open to further discussion. If you have specific examples or use cases where the property-based approach would significantly improve usability or code clarity, we'd love to hear them. Your practical experience with these instruments is extremely valuable to us as we shape the future of py-lab-hal.

Thank you again for your contributions to this discussion. Your feedback is helping us build a better tool for the entire community.

Best regards, James on behalf of the py-lab-hal team

[mvanriet]

Hello James,

Thank you for the elaborate answer. I work in a small company, and we're struggling to get a decent library to take shape, so I wouldn't consider my comments as Expert advice with capital 'E' :-)

I will look further into py-lab-hal, but it will take quite some time.

For inspiration, I would suggest to look at the description of the interface classes in the IVI specifications : Instrument classes.

Sidenote: IMHO, mypsu.channel[0].voltage = 5 is not simple attribute access. It involves sending a command to the device.

Best regards, Marc