feat: NeverNone to always generate an optional field, and AlwaysNone #677
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
iloveitaly
changed the title
iloveitaly
force-pushed
the
never-none
branch
2 times, most recently
from
a86e363 to
4d86cc1
Compare
Contributor
Author
|
@adhtruong fixed up tests for this! Take a look when you can. |
|
Documentation preview will be available shortly at https://litestar-org.github.io/polyfactory-docs-preview/677 |
adhtruong
reviewed
Apr 18, 2025
| """A factory field that marks as always generated, even if it's an optional.""" | ||
|
|
||
|
|
||
| class AlwaysNone: |
Collaborator
There was a problem hiding this comment.
Is this required? Does
from dataclasses import dataclass
from polyfactory.factories.dataclass_factory import DataclassFactory
@dataclass
class A:
a: int | None
class Factory(DataclassFactory[A]):
a = None
print(Factory.batch(size=10))work for this use case? Could this be documented
| if isinstance(field_value, Fixture): | ||
| return field_value.to_value() | ||
|
|
||
| # if a raw lambda is passed, invoke it |
Collaborator
There was a problem hiding this comment.
nit: this applies to all callables rather than just lambdas. Can this be updated?
Contributor
Author
|
Just a friendly reminder about this pull request! Please let me know if there's anything else needed here. |
|
This would also be useful to me! |
Co-authored-by: Andrew Truong <[email protected]>
iloveitaly
pushed a commit
to iloveitaly/polyfactory
that referenced
this pull request
Nov 14, 2025
- Update comment in base.py to say "callable" instead of "raw lambda" to accurately reflect that the code handles all callables, not just lambdas - Complete the incomplete comment in test_nones.py - Add comprehensive tests comparing AlwaysNone with plain None assignment - Add test demonstrating NeverNone behavior with __allow_none_optionals__ These changes address @adhtruong's review feedback while documenting that plain `name = None` works similarly to `AlwaysNone()`, though AlwaysNone provides more explicit intent and is processed differently internally. NeverNone provides unique value for per-field control of optional field generation.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Right now, there is not an ergonomic way to mark a single field as "required" in the sense
that polyfactory should always generate a value for it, even if it's marked as optional.
Curious what you think about the approach, I still need to:
Closes
#655