Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upRename Schema to Field? #577
Comments
This comment has been minimized.
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
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? |
This comment has been minimized.
This comment has been minimized.
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 |
This comment has been minimized.
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
Perfect. So, the current And how should the current In summary, the next parts will be:
|
This comment has been minimized.
This comment has been minimized.
Looks good, I think current field becomes |
This comment has been minimized.
This comment has been minimized.
Correction, Better to rename what used to be called |
This comment has been minimized.
This comment has been minimized.
+1 for |
This comment has been minimized.
This comment has been minimized.
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 |
This comment has been minimized.
This comment has been minimized.
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? |
This comment has been minimized.
This comment has been minimized.
@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. |
This comment has been minimized.
This comment has been minimized.
@skewty for what it’s worth, I’m not sure it’s actually that big of a downside for the following reasons:
|
This comment has been minimized.
This comment has been minimized.
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?