Skip to content

MNT: Deprecate FontProperties(pattern) #28837

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
wants to merge 1 commit into from
Closed

MNT: Deprecate FontProperties(pattern) #28837

wants to merge 1 commit into from
+77 −18

Conversation

timhoffm
Copy link
Member

@timhoffm timhoffm commented Sep 18, 2024 •
edited
Loading

... and use FontProperties.from_pattern() instead.

FontProperties(pattern) was an overloaded API that easily conflicts with FontProperties(family). The parameter was assumed to be a pattern if it was a string and the only parameter.

Noted in #28836 (review).

@timhoffm timhoffm added this to the v3.10.0 milestone Sep 18, 2024
@timhoffm timhoffm mentioned this pull request Sep 18, 2024
Merged
@timhoffm
MNT: Deprecate FontProperties(pattern)
f63e438 
... and use `FontProperties.from_pattern()` instead.

`FontProperties(pattern)` was an overloaded API that easily conflicts
with `FontProperties(family)`. The parameter was assumed to be a
pattern if it was a string and the only parameter.
@timhoffm timhoffm force-pushed the FontProperties-pattern branch from 86f308d to f63e438 Compare September 18, 2024 22:16
@anntzer
Copy link
Contributor

anntzer commented Sep 18, 2024

See also the item starting with "The FP constructor is a bit a mess..." at #10249, I guess.
Based on the writeup at #10249 I vaguely suspect we should rather deprecate FP(family) because that's easily written as FP(family=family) (consistently with all other attributes), and if anything the constructor without named parameter should take a pattern (... perhaps a CSS pattern, but that's another issue).

@timhoffm timhoffm marked this pull request as draft September 18, 2024 23:30
@timhoffm
Copy link
Member Author

Sure. We could do __init__(pattern=None, /, *, family=None, ...). Notes:

  • We still need an either pattern or the other parameters internal check, i.e. we have two orthogonal APIs in the constructor, but at least they are logically separated.
  • for the deprecation: can we detect whether a given single parameter is a family rather than a pattern?

@timhoffm timhoffm added the status: needs comment/discussion needs consensus on next step label Sep 18, 2024
@anntzer
Copy link
Contributor

anntzer commented Sep 19, 2024

  • for the deprecation: can we detect whether a given single parameter is a family rather than a pattern?

In the single-arg case, I would try calling parse_fontconfig_pattern, then if it raises, treat as a family (and warn) (If it doesn't raise, this can also occur if the family and the pattern are identical, e.g. "Times" parses as {"family": "Times"}.)

@timhoffm timhoffm mentioned this pull request Sep 19, 2024
Merged
@timhoffm
Copy link
Member Author

Superseeded by #28843.

@timhoffm timhoffm closed this Sep 19, 2024
@QuLogic QuLogic removed this from the v3.10.0 milestone Sep 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
status: needs comment/discussion needs consensus on next step status: superseded
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@timhoffm @anntzer @QuLogic