Does this have a knock on effect for the way that return_cpos=True from Plotter.show is sometimes used? For example, a common use case, at least for me is to use return_cpos=True and then copy and paste the value into my code to use as the starting point. I think this change would remove the ability of quick copy-paste?

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 96.40%. Comparing base (91f044c) to head (54e57bb).
⚠️ Report is 8 commits behind head on main.

@@           Coverage Diff           @@
##             main    #7794   +/-   ##
=======================================
  Coverage   96.40%   96.40%           
=======================================
  Files         150      150           
  Lines       32656    32658    +2     
  Branches     4114     4114           
=======================================
+ Hits        31482    31485    +3     
+ Misses        570      569    -1     
  Partials      604      604           

Does this have a knock on effect for the way that return_cpos=True from Plotter.show is sometimes used? For example, a common use case, at least for me is to use return_cpos=True and then copy and paste the value into my code to use as the starting point. I think this change would remove the ability of quick copy-paste?

Yes you're right, this would change that. You should still be able to copy/paste it as-is and use it, since the repr should be useable to init a new CameraPosition object but will need to prepend pv.

We could keep the old behavior with __str__. Using print(cpos) will call __str__, so you can keep the old representation that way.

🚀 Deployed on https://689bc838a34d5458720e6035--pyvista-dev.netlify.app

Both str and repr are implemented now. The output is consistent with what NumPy does in the sense that array() is included in the repr, but not str output

NDArray:

repr(np.array((1,)))  # 'array([1])'
str(np.array((1,)))  # '[1]'

CameraPosition

# repr
CameraPosition(position=(0.3914, 0.4542, 0.767),
               focal_point=(0.0243, 0.0336, -0.0222),
               viewup=(-0.2148, 0.8998, -0.3796))

# str
[(0.3914, 0.4542, 0.767),
 (0.0243, 0.0336, -0.0222),
 (-0.2148, 0.8998, -0.3796)]

I'm +0.2 in favor of this (out of -1 to +1). It is now easier to know what the numbers refer to. One hesitation is that, I assume that, there are a decent number of people who are using environments that show the repr, and that they are using return_cpos to find the final camera position. For example ipython and our own documentation building. One way to soften this blow would be to support this with better documentation. An example is that current show has this in the example. There are likely more of this throughout the documentation.

That's a good find, I wonder why that doctest is skipped.

Will do a search for cpos and try to update those examples. We can show both use cases, and maybe use print instead of str in the docs as that may also be more intuitive.

Users can still copy/paste and reuse the output as new input for a cpos keyword, so that functionality isn't really lost. And now if they need to make minor tweaks to CameraPosition.position, it is immediately obvious to users that (1) camera position is more than just a position vector, and (2) it's clear which of the three vectors needs to be changed.

That's a good find, I wonder why that doctest is skipped.

It's skipped because it raises a RuntimeError otherwise:
https://github.com/pyvista/pyvista/actions/runs/16918236508/job/47937498711#step:10:2145

RuntimeError: This plotter has been closed and cannot be shown. [docutils]

One hesitation is that, I assume that, there are a decent number of people who are using environments that show the repr, and that they are using return_cpos to find the final camera position. For example ipython and our own documentation building. One way to soften this blow would be to support this with better documentation. An example is that current show has this in the example. There are likely more of this throughout the documentation.

CameraPosition is now used explicitly in all examples to set cpos instead of a list of tuples. @MatthewFlamm does this address your concerns?