Skip to content

Copy defaults on construction and treat a string reserved_attrs as one field - #82

Open
00200200 wants to merge 1 commit into
nhairs:mainfrom
00200200:fix/copy-defaults-and-string-reserved-attrs
Open

00200200 wants to merge 1 commit into
nhairs:mainfrom
00200200:fix/copy-defaults-and-string-reserved-attrs

Conversation

@00200200

Copy link
Copy Markdown

Why

rename_fields and static_fields are already copied on construction so DictConfigurator ext:// / cfg:// prefixes convert (ConvertingDict only converts on __getitem__) and so later mutation of the caller's dict cannot change formatter state. defaults was stored by reference, so it missed both of those guarantees.

reserved_attrs is typed as Sequence[str]. A str is a sequence of characters, so reserved_attrs="filename" reserved the letters f, i, l, e, n, a, m instead of the field filename.

Summary of changes

  • Copy defaults the same way as rename_fields and static_fields.
  • Treat a string reserved_attrs value as a single field name.
  • Tests for caller-dict isolation, DictConfigurator conversion of defaults, and a string reserved_attrs.

Follow-up to the DictConfigurator copying in #45; defaults was enabled in 3.2 but was not copied.

How tested

  • pytest tests (88 passed), including the new cases in tests/test_formatters.py and tests/test_dictconfig.py.
  • black --check src tests

…e field.

defaults was stored by reference, so mutating the caller's dict (or leaving
a DictConfigurator ConvertingDict in place) could change later log output.
Copy it the same way as rename_fields and static_fields. A string reserved_attrs
value is a Sequence of characters, so wrap it as a single field name.

This branch has not been deployed

No deployments
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 this pull request may close these issues.

1 participant