Refactor summary_lines to ChainPairScoreResults dataclass

[Copilot]

Introduces a ChainPairScoreResults dataclass for chain-pair summary scores, matching the existing PerResScoreResults pattern. Replaces list[str] with structured data and strict formatting methods.

Changes

• New ChainPairScoreResults dataclass with 24 fields for chain-pair metrics (Chn1/Chn2, PAE/Dist cutoffs, ipSAE variants, pDockQ/pDockQ2, LIS, n0/d0 values, etc.)
• Formatting methods: to_formatted_line(), header_line(), csv_header_line() for consistent output
• Renamed ScoreResults.summary_lines: list[str] → chain_pair_scores: list[ChainPairScoreResults]
• Renamed ScoreResults.by_res_data → by_res_scores for consistency
• Updated aggregate_byres_scores() to return list[ChainPairScoreResults]
• Updated write_outputs() and main() to use dataclass methods

@dataclass
class ChainPairScoreResults:
    Chn1: str
    Chn2: str
    PAE: int
    Dist: int
    Type: str  # "asym" or "max"
    ipSAE: float
    # ... 18 more fields
    
    def to_formatted_line(self) -> str:
        """Fixed-width string matching original output format."""
        ...
    
    @staticmethod
    def header_line() -> str:
        ...

Output files verified identical to existing examples for AF2 and AF3 model types.

Original prompt

Similar to PerResScoreResults in ipsae.py, refactor summary_lines to use its own dataclass. Be very strict about the line formatting. Modify corresponding functions that use the results to write to stdout or text files.

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[y1zhou]

@copilot Change the class name to ChainPairScoreResults. For ScoreResults, change the corresponding field name to chain_pair_scores. Also change the by_res_data to by_res_scores to be consistent.

[Copilot]

@copilot Change the class name to ChainPairScoreResults. For ScoreResults, change the corresponding field name to chain_pair_scores. Also change the by_res_data to by_res_scores to be consis...

Done in 1e11f5a. Renamed:

• SummaryResult → ChainPairScoreResults
• summary_data → chain_pair_scores
• by_res_data → by_res_scores

[y1zhou]

@copilot What are some potential ways of refactoring the pymol_script strings as well? They are not as structured.

[Copilot]

@copilot What are some potential ways of refactoring the pymol_script strings as well? They are not as structured.

The pymol_script contains two types of lines:

1. Comment lines - Already derived from ChainPairScoreResults.to_formatted_line() with a # prefix
2. Alias commands - e.g., alias color_A_B, color gray80, all; color magenta, chain A and resi 3-119; ...

Potential refactoring approaches:

Option 1: PyMOLCommand dataclass hierarchy

@dataclass
class PyMOLAliasCommand:
    name: str  # e.g., "color_A_B"
    chain1: str
    chain2: str
    color1: str
    color2: str
    resi_ranges1: str
    resi_ranges2: str
    
    def to_line(self) -> str: ...

Option 2: Extend ChainPairScoreResults
Add a to_pymol_alias() method to ChainPairScoreResults that generates the alias command (would need residue range info passed in or stored).

Option 3: Separate PyMOLScript dataclass

@dataclass
class PyMOLScript:
    header: str
    chain_pair_comments: list[str]  # from ChainPairScoreResults
    alias_commands: list[PyMOLAliasCommand]
    
    def to_lines(self) -> list[str]: ...

Option 1 is cleanest for the alias commands. Option 3 provides the best structure for the full script. The challenge is that alias commands need residue range data that isn't currently in ChainPairScoreResults.