Stop models converting to camelCase#173
Conversation
|
I would be in favour of this. Having the request format be able to take multiple forms just add confusion. eg how would it handle requests for def demo(foo_bar: int = 42, fooBar: str = "42") -> MsgGenerator:
passIt's a slightly contrived example but I don't see the benefit to allowing variations in general. |
|
I think you're right, I was assuming that code formatters would shout at people trying to use camel case arguments, but we can't rely on everyone having a formatter. |
412e19d to
648e212
Compare
|
If no one strongly objects I'm going to merge this, will make life easier for artemis purposes |
Codecov Report
@@ Coverage Diff @@
## main #173 +/- ##
==========================================
- Coverage 89.90% 89.87% -0.03%
==========================================
Files 41 41
Lines 1248 1245 -3
==========================================
- Hits 1122 1119 -3
Misses 126 126
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
tpoliaw
left a comment
There was a problem hiding this comment.
Should non-plan models still allow camelCase aliasing? Seems weird if it works in some places but not others.
14a9392 to
453363d
Compare
d528cd3 to
b9d0975
Compare
b1094be to
6d18720
Compare
Previously with #132, all config, API parameter and plan model parameter names were converted to camelCase when loaded externally (e.g. from JSON). So
Would accept the following via the API:
{"taskName": "my task"}and a plan like
Would accept:
{"name": "my_plan", "params": {"fooBar": "qwerty"}}This PR removes all aliasing and we accept that there are snake_case models