(RUF012) Fixed mutable class Defaults- Task 2

[ananyakaligal]

Part of #10196
NOTE: These are NOT automated changes, they are done by hand
This pull request addresses Part of RUF012 Rule - Task 2, with a focus on enhancing code quality and resolving linting issues related to mutable class attributes.

Technical Details:

• Updated Files: The ClassVar annotations were added to mutable class attributes in two files, ensuring they are treated as class-level attributes. This change resolves the RUF012 linting issues.
• Remaining File: The update could not be applied to plugins/worksearch/schemes/editions.py due to a shared base class with the files mentioned in Task 1, which would introduce an overriding issue. Therefore, the change was not feasible for this file.
• Type Safety: Added proper type hints for better clarity and type safety throughout the affected files.

Testing:
Ran ruff check --select RUF012 to confirm that no further warnings related to mutable class attributes remain.

Screenshot:
N/A
Stakeholders:
@RayBB

[RayBB]

As far as I'm concerned this looks good.
However, I'm going to need to get a second opinion from staff

[RayBB]

@ananyakaligal I looked at this with Drini and we realized we probably don't want all these values to be mutable.
Can you review and add non-mutable options to this (unless it needs to be mutable).

See https://docs.astral.sh/ruff/rules/mutable-class-default/

[ananyakaligal]

@RayBB sure, I will work on this.

[RayBB]

@ananyakaligal any update on this?

[ananyakaligal]

Hey @RayBB, My schedule has been pretty packed, and I'm working on the preview button right now. The CSS part of that is a bit much and very specific, so it's taking some time. I'll definitely work on this by the end of this week. My apologies!

[RayBB]

No problem. Marking as draft until it's ready 👍

[ananyakaligal]

@RayBB I used MappingProxyType to ensure immutability, as I encountered dictionaries throughout and wanted to maintain consistency. Now, I will investigate the files where the class variable overriding issue popped up.

[ananyakaligal]

@RayBB
I’ve analyzed the behavior of several variables in the SearchScheme parent class (e.g., facet_fields, field_name_map, etc.), which are currently treated as instance variables. This design makes it challenging to override or modify these variables in the EditionSearchScheme child class without encountering errors like "cannot override instance variable with class variable."

Proposed Solutions:

1.Use Instance Variables
Define all variables (e.g., facet_fields, field_name_map, etc.) as instance variables explicitly in both parent and child classes via init.
Pros: Isolated per instance.
Cons: Requires explicit initialization for every instance.

class SearchScheme:
    def __init__(self):
        self.facet_fields: set[str] = set()
        self.field_name_map: dict[str, str] = {}

class EditionSearchScheme(SearchScheme):
    def __init__(self):
        super().__init__()
        self.facet_fields = {"field1", "field2"}
        self.field_name_map = {"title": "new_title"}

2.Use Immutable Types
Convert all variables into immutable, class-level attributes (e.g., frozenset, tuple) if they should remain constant across instances.
Pros: Shared and unmodifiable.
Cons: Limited flexibility if dynamic updates are needed.

class SearchScheme:
    facet_fields = frozenset()
    field_name_map = {}

class EditionSearchScheme(SearchScheme):
    facet_fields = frozenset({"field1", "field2"})
    field_name_map = {"title": "new_title"}

3.Rename in Child Class
Introduce new variable names in the child class to avoid overriding conflicts.
Pros: Avoids conflicts entirely.
Cons: May lead to inconsistencies in the codebase.

class SearchScheme:
    facet_fields = set()
    field_name_map = {}

class EditionSearchScheme(SearchScheme):
    edition_facet_fields = {"field1", "field2"}
    edition_field_name_map = {"title": "new_title"}

Considering these solutions, which approach do you recommend for managing multiple variables like facet_fields and field_name_map? Should we refactor the parent class to enforce a consistent approach across its attributes?

[ananyakaligal]

@RayBB Could you please provide your feedback on the solutions I proposed earlier?

[RayBB]

I see how messy this one is really great work diving in on it. Lets move openlibrary/plugins/worksearch/schemes/editions.py to be part of #10283
In general the approach we'll want (when moving to the other PR) is:

• By default, assume it should be moved to an immutable type.
• Check if there is anywhere that is is being changed
• If it is being changed somewhere we'll need to discuss but it should then probably become and instance variable.

[RayBB]

PS: I went ahead and removed the editions.py changes so Drini and I can review this one tomorrow. Hopefully merge it!

[cdrini]

Awesome thank you @ananyakaligal ! One change request for you in the testing file ; the schema file looks good.

[ananyakaligal]

@cdrini I hope I have made all the changes as requested.

[cdrini]

Lgtm, nice work @ananyakaligal !