Remove mutable defaults and allow more generic types #357
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.
Summary
Solve #353 and #354 by removing mutable defaults and allowing more generic types than just
list
s/tuple
s/set
s.Details
Mutable defaults
Mutable defaults are a bad idea since they're evaluated at definition time and mutating a default value in 1 instance will mutate it in all of them.
This PR solves bad mutable defaults by allowing the user to pass (and defaulting to)
None
, which retains the old behavior.More generic types
The code already worked for any
Iterable
s, as we only iterated on the values. These changes reflect that reality by not forcing the user to passlist
s, but allowing them to pass any iterables and storing them aslist
s internally (to not change the API).str_types
deprecationstr_types
is a legacy thing from when the library supported Python 2, where thestr_types
werestr
andunicode
. This PR deprecates the variable in favour of checking againststr
. This is a minor internal tweak.Questions
I replaced the
AssertionError
s with more aptly (IMO) suitedTypeError
s andValueError
s. Do you think this constitute a breaking change? Given the errors were raised only upon instantiation for validation and that they were undocumented behaviour, I'd say these are not breaking.Notes
I'm totally open to any critique/requests, and even to not merging the PR if you think it's not a good idea. Just let me know!