labthings / labthings/labthings-fastapi
Clearer error messages for ThingClients when called with positional args.
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 9
- Forks
- 4
- PR merge metrics
- No merged PRs in 30d
Description
I kept getting an error ThingName.action_name() takes1 positional arguments but 2 were given
As this was showing me the name of the Thing, which does take 2 positional arguments I spent a long time trying to trace the error which isn't easy due to the confusing traceback.
After a lot of debugging I now realise that ThingClients only take keyword arguments. It would be good to detect this issue and have an explicit error message like: ThingClient Actions must always be called with keyword arguments.
I don't understand well enough where the error is actually raised for both types of clients, but it would be good to detect this and report the correct behaviour.
My first thought was a:
POS_ARG_REGEX = re.compile(r".* takes [0-9]+ positional arguments but [0-9]+ were given")
# And then later
try:
# Whatever is causing the error
except TypeError as e:
if POS_ARG_REGEX.match(str(e)):
raise TypeError("ThingClient Actions must always be called with keyword arguments.") from e
raise e
"""
but this is a bit fragile.
As I think more, somewhere it might be worth just collecting `*args` as well as `**kwargs` and then raising "ThingClient Actions must always be called with keyword arguments." if the length of `args` isn't 0?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
The issue names no files or tests. Start by locating the ThingClient action invocation and the path where positional arguments currently produce a TypeError; then add coverage for both client types. Done means positional calls receive the explicit keyword-only error while valid keyword calls continue to work.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- fastapi, python
- Domain
- api, backend
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100