-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Raise exception if you put app.function on a class method #1985
Conversation
will look at unit test failures later |
1939e2a
to
987613b
Compare
Am I doing something wrong here?
|
modal/app.py
Outdated
```python | ||
@app.cls() | ||
class MyClass: | ||
@method() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@method() | |
@modal.method() |
to be more consistent with the prose, and because I think this is a better default style for our docs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the docs mostly use @method()
rather than @modal.method
. No super strong feelings but I think consistency favors the former?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By consistency I meant that the text of the error message has
Please use
@app.cls
with@modal.method
instead.
I agree we're not very consistent with the docs, and personally would prefer always using the full modal.<function>
spelling. Otherwise it is annoying because you need to update both the code where the error was raised and also change your imports. Additionally, since we use such general names, we run the risk of cascading confusing errors if the user happened to have a variable named method
or whatever in their script (this is riskiest with exit
, which is a built-in function).
Note that the ambiguity would be eliminated if the partial function decorators were methods on App
instead of standalone functions in the modal
namespace :)
Sorry @mwaskom I think something broke when I rebased this on latest main. I'll ping you once I fixed it and all tests are passing. |
Related confusing error that I just ran into when I forgot
|
oh cool let's try to fix that one too |
ebc1877
to
ce0dcf0
Compare
ce0dcf0
to
be4ab84
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
dedent( | ||
""" | ||
The `@app.function` decorator must apply to functions in global scope, | ||
unless `serialize=True` is set. | ||
If trying to apply additional decorators, they may need to use `functools.wraps`. | ||
""" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this this error obviate the one we have here:
modal-client/modal/_utils/function_utils.py
Lines 110 to 114 in ded0d09
raise InvalidError( | |
f"Cannot wrap `{f.__qualname__}`:" | |
" functions and classes used in Modal must be defined in global scope." | |
" If trying to apply additional decorators, they may need to use `functools.wraps`." | |
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, the other one is for situations where the a function is defined in local scope, i.e. inside another function.
The one we're adding is for global scope but not top-level scope.
Thanks @mwaskom ! |
Quickfix for something a user ran into. User had code like this:The issue is that
@app.function
should be@method()
and you need a@app.cls
instead.However this code currently fails with this very user-unfriendly error:
After this PR, it outputs this instead:
EDIT: this ended up being a bit more work than anticipated. I moved some code out of function_utils.py into app.py instead since it felt very Modal-specific. Passes all integration tests so hopefully it works!