-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Protected namespaces #4915
Comments
I imagine you've considered this before but I want to bring it up here since it's directly related: could we avoiding protected namespaces altogether by making these methods free floating functions like they are for dataclasses? from pydantic import BaseModel, to_json
class MyModel(BaseModel):
json: Any
to_json(MyModel(json={})) I think the main cons would be:
|
I've thought about this a lot, see #1001. I even pitched a slightly crazy idea at the language summit at pycon last year and got shot down, see here. I really don't want to loose the great DX of However we will need an equivalent of |
Oh yeah I remember this discussion 😄
I think this is a really strong argument for having them as top level methods! I don't think concerns over frameworks like FastAPI accessing the shadowed methods and finding a user field instead hold water: it would be easy to say that frameworks should always use the top level methods. An extra line of code or two in a framework is not a problem, it's the end-user DX where every character typed really matters. I also don't think autocompletion is a big deal: we're just using Would you be concerned at all with internal implementation bits? Top level methods would have a hard time modifying the model or accessing private things. |
I agreed, also most customisation will be via If we kept the names unchanged:
Then it would be even easier for end users. |
Sorry just to clarify, are you agreeing that top level methods with convenience aliases on the model class are the way to go? |
Yes exactly. The "what should FastAPI do" question is a bit more complicated, but doesn't need to be decided now. |
Awesome. I guess then the discussion is:
So then I would call this a "soft" protection. We'd add something to the docs along the lines of "Pydantic uses the |
On extra we definitely need a hard block - either validation error or matching item are just ignored. For fields I would argue for a hard block (error) too, but I guess we could use a |
A suggestion I'd like to offer for consideration: retaining the convenience methods with public names, but instead of using I think using the double underscore would significantly reduce the opportunity for conflicts in the course of normal usage (e.g., wanting to have a field named I personally don't think the double underscore would have a significant impact on readability or aesthetic of the code, but I wouldn't be surprised by disagreement 😅. |
We should include |
This is waiting on #4617 |
Do you mean a variant of |
Dataclasses ( |
Hi, it would have been great if |
@seperman could you use dataclasses and TypeAdapter for your use case? If it's FastAPI you won't even need to use |
@adriangb Can you please point me to the right resource? Yes I'm using FastApi. |
https://fastapi.tiangolo.com/advanced/dataclasses/ The pro, for your use case, is that there’s no protected namespace. The (general) con is that not all of the same features are supported and that you’d have to use a TypeAdapter (https://docs.pydantic.dev/latest/api/type_adapter/) to get validation outside of FasAPI (that may even be a pro). A lot of the Pydantic features will still work if you use Annotated, eg |
Cool. Thanks @adriangb ! |
See #4617.
We need to:
model_
config.extra = 'allow'
ignore extra items which conflict with these namespaces - maybe not!I think it's okay for users to add methods which conflict with namespaces, though we should warn in the docs that that could break in future.
The text was updated successfully, but these errors were encountered: