Skip to content

support new file format from leetgo#5

Open
zodman wants to merge 3 commits into
ergs0204:mainfrom
zodman:support-text-input-output
Open

support new file format from leetgo#5
zodman wants to merge 3 commits into
ergs0204:mainfrom
zodman:support-text-input-output

Conversation

@zodman

@zodman zodman commented Jan 29, 2026

Copy link
Copy Markdown

Your lib looks interesting.

Im just make some changes for my personal use. Should I improve it ?

I can make interoperation with leetgo, supporting his format of test cases... What do you think? should I add documentation ?

@gemini-code-assist

Copy link
Copy Markdown
Contributor

Summary of Changes

Hello @zodman, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances the pyleet library's test case loading capabilities by introducing compatibility with the leetgo test case format. This integration allows pyleet to process test cases generated by leetgo, broadening the range of external tools and formats it can interoperate with, and providing more flexibility for users in how they define and load their test data.

Highlights

  • New Test Case Format Support: Implemented support for the leetgo test case format, enabling parsing of test cases structured with "input:" and "output:" markers.
  • Generic Plain Text Parsing: Introduced a new utility function, _plain_text, to handle a generic plain text test case format where each line is an evaluable Python tuple.
  • Enhanced Test Case Loading Logic: Updated the load_test_cases function to prioritize parsing leetgo formatted plain text before falling back to the generic plain text format.
  • Code Style Improvements: Applied minor code style improvements, including consistent use of double quotes for dictionary keys and better f-string formatting for error messages.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Comment thread pyleet/testcase_loader.py Outdated
try:
return _plain_text_input(content)
except Exception:
import traceback

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeap I need remove this

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request adds support for the leetgo test case format. The implementation introduces a new parsing function _plain_text_input and integrates it into load_test_cases.

My review found a couple of issues:

  1. The new parsing function _plain_text_input has several bugs, including shadowing built-ins, and is not robust against malformed input, which could lead to AttributeError or IndexError.
  2. The new control flow in load_test_cases for trying different plain text formats contains a critical logic error with unreachable code and poor exception handling, which prevents the fallback parsing mechanism from working.

I've provided suggestions to fix these issues to make the new functionality more robust and correct. The other changes are minor stylistic improvements which look good.

Regarding your question in the PR description, yes, adding documentation for the newly supported format would be very helpful for users. You could update the docstring of load_test_cases or a relevant markdown file.

Comment thread pyleet/testcase_loader.py Outdated
Comment thread pyleet/testcase_loader.py Outdated
Comment on lines +32 to +51
def _plain_text_input(content):
"""from leetgo format: https://github.com/j178/leetgo?tab=readme-ov-file#testcasestxt"""
raw_cases = content.split("\n\n")
_cases = []
for raw_case in raw_cases:
lines = raw_case.splitlines()
input = []
output = []
res = None
for ln in lines:
if "input:" in ln:
res = input
continue
if "output:" in ln:
res = output
continue
res.append(json.loads(ln))
_cases.append([input, output])

return [[input, output[0]] for [input, output] in _cases]

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

This function for parsing the leetgo format has a few issues that make it fragile:

  • It uses input and output as variable names, which shadow Python's built-in functions. This is generally discouraged.
  • If a test case chunk has content before the input: marker, res.append() will be called on None, raising an AttributeError.
  • The expression output[0] will raise an IndexError if a test case is missing an output: section.
  • The check if "input:" in ln is not robust and could match lines that are not the intended markers (e.g., a comment containing 'input:').

Consider refactoring this function to be more robust and readable. Here is a suggested implementation that addresses these points.

def _plain_text_input(content):
    """from leetgo format: https://github.com/j178/leetgo?tab=readme-ov-file#testcasestxt"""
    raw_cases = content.strip().split("\n\n")
    cases = []
    for raw_case in filter(None, raw_cases):
        lines = raw_case.splitlines()
        input_data = []
        output_data = []
        current_section = None
        for line in lines:
            stripped = line.strip()
            if stripped == "input:":
                current_section = input_data
            elif stripped == "output:":
                current_section = output_data
            elif current_section is not None and stripped:
                current_section.append(json.loads(line))

        if not output_data:
            raise ValueError(f"Test case is missing 'output:' section or value: {raw_case}")
        
        cases.append([input_data, output_data[0]])
    return cases

zodman and others added 2 commits January 28, 2026 23:33
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>

@ergs0204 ergs0204 left a comment

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for contributing this. Leetgo compatibility would be useful. Before merging, please add documentation plus tests covering multiple inputs, strings, blank output, malformed blocks, and fallback to Pyleet plain-text cases. The parser should also validate that both input: and output: are present: the current and condition accepts a block missing either marker, and the broad except Exception can hide malformed Leetgo data by silently falling back to the other parser. Once those cases are covered, I can review the behavior with confidence.

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.

2 participants