labthings / labthings/labthings-fastapi

Clearer error messages for ThingClients when called with positional args.

Open
#140 0 comments 0 reactions 0 assignees View on GitHub

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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.