feat!: Prefer title attributes when naming Python parameters/properties.

[dbanty]

Closes #602

@jselig-rigetti will you give this a try to ensure it fixes the issue you bumped into? And also give it a review please 😄

[codecov]

Codecov Report

Merging #606 (35e0261) into main (26e7e0f) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##              main      #606   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           49        49           
  Lines         1713      1714    +1     
=========================================
+ Hits          1713      1714    +1     

Impacted Files	Coverage Δ
...penapi_python_client/parser/properties/__init__.py	100.00% <100.00%> (ø)
..._python_client/parser/properties/model_property.py	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 26e7e0f...35e0261. Read the comment docs.

[jselig-rigetti]

Thanks for this! Looks good to me, might be overkill but I can see it being desirable to have an exclude/include configurability for this behavior akin to something like #560 - I can take a look at doing this myself if that makes sense (probably doesn't have to be part of this PR)

I saw a the following error in both of the below situations, which is to be expected:

Warning(s) encountered while generating.
Client was generated, but some pieces may be missing

Titles collide, previously not an error but will be one now.

properties:
  b:
    title: a
  c:
    title: a

Title collides with property key, previously and still an error.

properties:
  _a:
    title: a
  a: {}

[dbanty]

I don't see a way to solve for the second case—there is always going to be some risk of collision, I think the best we can do is give as many tools as possible to avoid them (e.g., change/set title). Maybe in the case of the first example, we fall back to using the key for both? So it would generate b and c instead of conflicting.

[dbanty]

@jselig-rigetti thinking about this again, I think the better move is going to be to swap around the behavior. So, instead of always preferring title, we go back to the previous behavior of using the property's key as the name. Then, only in cases on conflicts, we switch to using the title. The good news is that means this is no longer a breaking change—it will just support generating code in more cases. The bad news is that it'll be a lot more work I think 😬

[dbanty]

Closing in favor of an override for property names via config (@jselig-rigetti is that somewhere you can upstream it?)