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
Rename Schema to Field? #577
Comments
Thanks for tagging me. Yep. I think it makes sense. If we can keep supporting it for a while with a deprecation warning, we should be fine. And thinking about it, it actually makes more sense for it to be Slightly related, currently a: int = Schema(...)
One way I'm "hacking" it in FastAPI (for stuff that inherits from Then because the return of the function is annotated as I think this is something that could be interesting to have here too, maybe worth considering during this change. |
In favour of this change too. This seems to align better with dataclass terminology too, https://docs.python.org/3/library/dataclasses.html#dataclasses.field. For consideration: is there a possibility that the similarity would be a bad thing, rather than good? |
I agree with @jasonkuhrt that using a Also, by implementing a I wanna take a shot at this. I have some naming questions:
On the other side, having just a function |
I think the function should be called The only question is what do we call the class? It would be confusing to also call it Please take a shot. I want to work on v1 features once v0.32 is released. |
Perfect. So, the current And how should the current In summary, the next parts will be:
|
Looks good, I think current field becomes |
Correction, Better to rename what used to be called |
+1 for |
This may be controversial, but the library attrs supported typing (before python 3.6) using a type parameter. class Foo(BaseModel):
maximum = Field(int, 100)
# this would require a different code path
class Bar(BaseModel):
maximum: int
# this would be bad but possible
class Foo(BaseModel):
maximum: int = Field(str, "100") Would having the type as an arg to the |
I see a variety of approaches to the possible signature of the I'm most in favor of one of the first two approaches, and would be fine with the first one (the current proposal).
@skewty do those points change your thinking at all? |
@dmontagu I hadn't mentally considered "Con: Incorrect type hint if you actually want to treat the result as a FieldType". Thank you. Given the above, I would choose method 1. |
@skewty for what it’s worth, I’m not sure it’s actually that big of a downside for the following reasons:
|
I created a separate issue for this, but there may be another alternative: @tiangolo this could also be useful to support in fastapi (where I could grab the |
Currently we have the class
Schema
for when you need to define more stuff on a field than just the type and default.But this is a confusing name since not all it's arguments refer to the schema. It'll get more confusing if we want to add more arguments to
Schema/Field
, eg. a more complex alias system #477.Therefore we should rename it to
Field
.This would require:
Field
class, perhaps renaming the entirefields.py
module.Schema
needs to carry on working for a while but with a deprecation warningWhat does everyone thing?
@tiangolo
Schema
was your work originally, are you ok with this?The text was updated successfully, but these errors were encountered: