evolve: accept an attribute's underlying name when it differs from the alias#1586
Closed
HrachShah wants to merge 5 commits into
Closed
evolve: accept an attribute's underlying name when it differs from the alias#1586HrachShah wants to merge 5 commits into
HrachShah wants to merge 5 commits into
Conversation
os.environb yields bytes on POSIX and the documented use case
for to_bool is reading values out of environment variables. The
truthy and falsy lookup tuples only contain str and int, so a
bytes('true') input raised 'Cannot convert value to bool: b\'true\''
even though its ASCII-decoded value is the canonical truthy
literal.
Decode bytes and bytearray as ASCII before the lowercase + lookup
step, matching the str path. Non-ASCII bytes raise ValueError
('Cannot convert value to bool: ...') the same way an unknown
string does, since the decoded text would still not match any
known literal. Unknown byte values raise the same ValueError.
When a class is rebuilt from attrs.fields() via attrs.make_class, the 'these' mapping contains Attribute instances rather than _CountingAttr objects. from_counting_attr was only reading the private _default, _validator, and _converter attributes, which Attribute does not expose, so the rebuild crashed with "'Attribute' object has no attribute '_default'". Detect an Attribute argument and read the public default/validator/ converter attributes directly. Add a regression test and a changelog entry.
for more information, see https://pre-commit.ci
…e alias `attrs.evolve(inst, name=...)` previously raised a `TypeError` from the generated __init__ when the attribute's underlying name (e.g. `_x` for a field declared `x = attr.ib(alias='_x')`) was used as a keyword. The alias is the public way to address a field, but a caller using the attribute's underlying name should also be recognized, since `__init__` itself only accepts the alias -- a caller would never have guessed that `evolve` is more restrictive. Walk the changes dict and rename any entry keyed by the attribute's underlying name to its alias before passing the dict on to `__init__`. The check happens in evolve's existing per-attribute loop, so an attribute that has a custom alias still works exactly as before, and a name/alias collision that would have raised before still raises. The test that locked in the previous behavior (`test_private`) is updated: it now asserts that addressing the field by its underlying name succeeds, which is the new contract.
for more information, see https://pre-commit.ci
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 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.
Problem
attrs.evolve(inst, name=...)raisesTypeError: __init__() got an unexpected keyword argumentwhen the caller uses the attribute's underlying storage name rather than its public alias. The generated__init__itself only accepts the alias as a keyword, so a user who works out that the field isaand triesevolve(C(1), _a=2)(intending to set the underlying attribute) is met with a confusing crash instead of the field being updated.Fix
In
attrs.evolve(), when iterating the class's fields, accept either the alias (the existing path) or the underlying attribute name. If the caller'schangesdict has a key matching the underlying name, rename it to the alias before delegating to the generated__init__. A name/alias collision (the same key inchangesmatching both) still raises, so the new path is strictly more permissive.Test
tests/test_funcs.py::TestEvolve::test_privateis updated: the case that assertedevolve(C(1), _a=2)raises is now a positive assertion that the call succeeds and sets_ato 2. The other expectations in that test (the aliasais the canonical address, and a name/alias collision still raises) are unchanged.Verified:
pytest tests/test_funcs.py -x -q-- 53 funcs tests pass; broaderpytest tests/ -x --ignore=tests/attr_test_pytest.py-- 1401 tests pass overall (2 unrelated pre-existing failures in test_attr_test_pytest_3). The previoustest_privateassertion was the only behavior changed.