I had a few questions related to this point:

1. Why not store also the properties in a dict, in case we want to pass all properties (for example, to define a new device, save as json for easy check of the specs, etc.)? I find having a string not always convenient (also it's supposed to be an internal method).
2. Why not implement _specs also for virtual devices? Following this tutorial, we could expect to be able to print the specs also for the derived virtual device.
3. Why implement _specs as an internal method and not as a public property?

I had a few questions related to this point:

1. Why not store also the properties in a `dict`, in case we want to pass all properties (for example, to define a new device, save as json for easy check of the specs, etc.)? I find having a string not always convenient (also it's supposed to be an internal method).

2. Why not implement `_specs` also for virtual devices? Following [this tutorial](https://pulser.readthedocs.io/en/stable/tutorials/virtual_devices.html), we could expect to be able to print the specs also for the derived virtual device.

3. Why implement `_specs` as an internal method and not as a public property?

The short answer is that the access and display of device specs has evolved somewhat carelessly. We need to improve the user interface, make sure it includes every parameter and that it is homogeneous between Device and VirtualDevice.
These are valuable suggestions, we'll keep them in mind!

Note that I just found the _params() internal method, which does work for both physical and virtual devices. However, it does not contain all parameters (for example, interaction_coefficient is missing, while interaction_coefficient_xy is present). It could also better be a public property.