8000 [MNT]: Deprecate mutability of FontProperties · Issue #22495 · matplotlib/matplotlib · GitHub
[go: up one dir, main page]

Skip to content
[MNT]: Deprecate mutability of FontProperties #22495
Open
@anntzer

Description

@anntzer

Summary

Currently, FontProperties (FPs) are mutable, which makes caching based on them a bit tricky (#22323, #22487). Manipulation is also not so nice; e.g. the fonts_demo.py example needs to repeatedly copy a base FP instance and call setters on the copies. Moreover, if one writes

fp = FontProperties(...)
textobj.set_fontproperties(fp)

then later mutation of fp doesn't modify the fontproperties on textobj, because set_fontproperties explicitly makes a copy of its argument. While this kind of "isolate-from-later-changes" is something we typically aim for in Matplotlib (see recent PRs likewise isolating artists from later changes in passed-in data arrays), this also means that there is basically no functionality gain coming from mutable FPs (and at least one complication, in the case of caching). (If set_fontproperties did not copy, then mutability would provide a way for two text objects to share exactly the same FP while having to mutate only one of them.)

I would therefore argue that the various property setters on FP should be deprecated to ultimately make FPs immutable; instead, we should use with_foo() methods that return new instances with just a single property being changed (similar to the pathlib API, for example). More precisely, we can either have with_family(family), with_style(style), with_variant(variant), etc., or instead we could also have a single with_props(**kwargs) (called e.g. as with_props(family="Times", ...)); I do 5A94 n't have a very strong opinion there.

Proposed fix

No response

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      0