Skip to content
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

Always set data_key #1864

Open
kasium opened this issue Aug 13, 2021 · 2 comments · May be fixed by #1897
Open

Always set data_key #1864

kasium opened this issue Aug 13, 2021 · 2 comments · May be fixed by #1897

Comments

@kasium
Copy link

kasium commented Aug 13, 2021

Hello all,

in my application we use and love marshmallow. We have a lot of dynamic coding, therefore we access fields e.g. over the declared_fields attribute. Also we need most of the time the Field.data_key attribute which is defined as str | None.

I would like to suggest an option, which always sets the data_key so that it will never be None. If the user provides it, fine. Else, just set it to the field name. I guess this could also simplify some coding, since you can expect that this attribute is always set.

What do you think?

@lafrech
Copy link
Member

lafrech commented Aug 31, 2021

I don't have any objection to this right away, assuming it is feasible without too much trouble.

It could happen in _bind_to_schema.

Anyone willing to work on this?

@kasium
Copy link
Author

kasium commented Aug 31, 2021

@lafrech I'm happy to take look, if you think it can be managed by somebody with no contributions to this project yet.

The _bind_to_schema seems to be the right place. However, how would you manage the typing? The data_key must still be defined as optional, because it will be potential None till it's bindend.
The intention of this issue is, to get rid of the optional

@lafrech lafrech linked a pull request Oct 27, 2021 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants