Answer A: Anthropic Claude Opus 4.7
import re import html def markdown_to_html(markdown_text: str) -> str: """Convert a subset of Markdown into HTML. Supported features: - Headers (# .. ######) - Unordered lists with 2-space nesting - Fenced code blocks (```) - Paragraphs - Inline: ***bold+italic***, **bold**, *italic* """ def escape(text: str) -> str: # Escape HTML-sensitive characters. return html.escape(text, quote=False) def process_inline(text: str) -> str: """Process inline markdown. Works on already-escaped text is fine since the markers *, ** and *** don'...
Show Full Answer ▼
import re import html def markdown_to_html(markdown_text: str) -> str: """Convert a subset of Markdown into HTML. Supported features: - Headers (# .. ######) - Unordered lists with 2-space nesting - Fenced code blocks (```) - Paragraphs - Inline: ***bold+italic***, **bold**, *italic* """ def escape(text: str) -> str: # Escape HTML-sensitive characters. return html.escape(text, quote=False) def process_inline(text: str) -> str: """Process inline markdown. Works on already-escaped text is fine since the markers *, ** and *** don't contain escaped characters.""" escaped = escape(text) # Order of precedence: ***, then **, then *. # Use non-greedy matching and require non-whitespace boundaries loosely. # ***text*** escaped = re.sub( r'\*\*\*(.+?)\*\*\*', r'<strong><em>\1</em></strong>', escaped, ) # **text** escaped = re.sub( r'\*\*(.+?)\*\*', r'<strong>\1</strong>', escaped, ) # *text* escaped = re.sub( r'\*(.+?)\*', r'<em>\1</em>', escaped, ) return escaped lines = markdown_text.split('\n') output = [] # State trackers in_code_block = False code_buffer = [] paragraph_buffer = [] # List stack: list of indent levels (0, 1, 2, ...) currently open list_stack = [] def flush_paragraph(): if paragraph_buffer: content = ' '.join(paragraph_buffer) output.append(f'<p>{process_inline(content)}</p>') paragraph_buffer.clear() def close_lists_to(level): """Close lists until only `level` lists remain open (level = number of open <ul>).""" while len(list_stack) > level: output.append('</li>') output.append('</ul>') list_stack.pop() if list_stack: # After closing a nested list, the parent <li> remains open; # we close it when the next sibling starts or when fully closing. pass def close_all_lists(): while list_stack: output.append('</li>') output.append('</ul>') list_stack.pop() i = 0 while i < len(lines): line = lines[i] # Code block handling if in_code_block: if line.strip().startswith('```'): # End code block code_content = '\n'.join(code_buffer) output.append(f'<pre><code>{escape(code_content)}</code></pre>') code_buffer = [] in_code_block = False else: code_buffer.append(line) i += 1 continue # Check for code block start stripped = line.strip() if stripped.startswith('```'): flush_paragraph() close_all_lists() in_code_block = True i += 1 continue # Blank line if stripped == '': flush_paragraph() close_all_lists() i += 1 continue # Header? header_match = re.match(r'^(#{1,6}) +(.*)$', line) if header_match: flush_paragraph() close_all_lists() level = len(header_match.group(1)) content = header_match.group(2).rstrip() output.append(f'<h{level}>{process_inline(content)}</h{level}>') i += 1 continue # List item? # Match leading spaces (must be even for nesting) followed by "- " list_match = re.match(r'^( *)- +(.*)$', line) if list_match: flush_paragraph() indent_spaces = len(list_match.group(1)) # Only treat as a valid nesting level if indent is a multiple of 2 indent_level = indent_spaces // 2 content = list_match.group(2) # Adjust list stack if not list_stack: # Starting fresh: first list must be at level 0 indent_level = 0 output.append('<ul>') list_stack.append(0) output.append(f'<li>{process_inline(content)}') else: current_depth = len(list_stack) - 1 # top index if indent_level > current_depth: # Open a new nested list (only go one level deeper at a time) indent_level = current_depth + 1 output.append('<ul>') list_stack.append(indent_level) output.append(f'<li>{process_inline(content)}') elif indent_level == current_depth: # Sibling at same level: close previous <li> output.append('</li>') output.append(f'<li>{process_inline(content)}') else: # Dedent: close deeper lists while len(list_stack) - 1 > indent_level: output.append('</li>') output.append('</ul>') list_stack.pop() # Also close the parent <li> that contained this nested list output.append('</li>') # Now at same level: add sibling output.append(f'<li>{process_inline(content)}') i += 1 continue # Otherwise, it's a paragraph line if list_stack: close_all_lists() paragraph_buffer.append(line.strip()) i += 1 # End of input: flush everything if in_code_block: # Unclosed code block: emit whatever we have code_content = '\n'.join(code_buffer) output.append(f'<pre><code>{escape(code_content)}</code></pre>') flush_paragraph() close_all_lists() return '\n'.join(output) if __name__ == '__main__': sample = '''# Header 1 This is a paragraph with **bold** and *italic* text. This is the same paragraph. - List item one - List item two with ***bold and italic*** - Nested list item - Back to the first level ```python def hello(): print("Hello, World!") ``` ''' print(markdown_to_html(sample))
Result
Winning Votes
0 / 3
Average Score
Total Score
Overall Comments
Answer A implements all required features and is well-structured with clear comments. The inline parser uses regex substitutions in order of precedence, which works for most cases but has a subtle flaw: it doesn't escape HTML characters before applying inline patterns, and the escape is applied first which could interfere with patterns. More critically, the list closing logic has a bug when dedenting: it emits an extra `</li>` for the parent item before re-opening at the same level, which can produce malformed HTML. The code block detection uses `line.strip().startswith('```')` which is slightly more lenient than needed. Overall it's a solid attempt with some edge case issues in list handling.
View Score Details ▼
Correctness
Weight 35%Answer A correctly handles headers, paragraphs, code blocks, and basic inline formatting. However, the list dedenting logic has a bug: when closing nested lists, it emits an extra `</li>` for the parent item which can produce malformed HTML. The inline regex approach can also match across unintended boundaries for unclosed markers like `*italic` potentially matching with a later `*` in the text.
Completeness
Weight 20%All required features are implemented: headers (h1-h6), unordered lists with nesting, code blocks with language specifier ignored, paragraphs, and all three inline styles (bold+italic, bold, italic). The main sample from the task is handled.
Code Quality
Weight 20%Code is well-organized with clear helper functions and good comments. The docstring is helpful. However, the list management logic is somewhat complex and has subtle bugs. The regex approach for inline parsing is simpler but less robust. The `close_lists_to` function is defined but not used in the main loop (only `close_all_lists` is used).
Practical Value
Weight 15%The solution works for common cases and includes a runnable `__main__` block with the sample input, which is helpful for testing. However, the list nesting bugs and potential inline regex issues reduce practical reliability for edge cases.
Instruction Following
Weight 10%Follows all specified instructions: correct function signature, supports all required features, handles the specified inline precedence order, doesn't implement unsupported features, and handles unclosed tags (though imperfectly with regex). HTML escaping is applied.
Total Score
Overall Comments
Implements the required block types and inline formatting with a simple state machine and regex-based inline substitutions, and correctly escapes HTML including inside code blocks. However, list generation has multiple structural issues: it emits </li> and </ul> sequences that can lead to invalid nesting, mishandles dedents (extra </li>), and can open nested <ul> without being inside a parent <li>. Inline handling via regex is not robust for tricky/malformed cases (e.g., overlapping markers like **bold *italic***), and it does not support recursive nesting of inline elements as required/expected.
View Score Details ▼
Correctness
Weight 35%Correct for basic headers/paragraphs/code blocks and simple emphasis, but list nesting/closing is frequently invalid (extra </li>, nested <ul> placement issues) and regex emphasis can mis-handle overlapping/nested cases (e.g., **bold *italic***).
Completeness
Weight 20%Covers all requested feature categories, but list nesting support is unreliable and inline nesting is not truly supported beyond simple patterns, reducing effective completeness.
Code Quality
Weight 20%Readable and modular, but list-stack logic is convoluted with unused/ineffective helper (close_lists_to) and fragile state transitions; heavy regex substitutions reduce clarity/robustness.
Practical Value
Weight 15%Useful for simple inputs, but invalid list HTML and emphasis edge cases limit real-world usability for the stated subset.
Instruction Following
Weight 10%Implements requested subset and ignores code-block language specifier; however, robustness requirement for tricky inline inputs and correct list nesting/termination is not well met.
Total Score
Overall Comments
Answer A presents a well-structured, state-machine-based solution that correctly handles most block-level elements like headers, paragraphs, and code blocks. However, its approach to parsing inline elements using sequential regular expression substitutions is fundamentally flawed. This method fails to correctly handle nested inline styles (e.g., bold containing italic), which is a significant correctness issue. The list-handling logic is also complex and less robust than the alternative.
View Score Details ▼
Correctness
Weight 35%The solution fails to correctly parse nested inline styles. For example, `**bold *italic* bold**` is incorrectly rendered because the sequential `re.sub` calls operate on the intermediate string containing newly added HTML tags. This is a significant correctness flaw in the parsing logic.
Completeness
Weight 20%The solution attempts to implement all required features. However, since the implementation of nested inline styles is incorrect, it cannot be considered fully complete in its functionality.
Code Quality
Weight 20%The code is generally well-structured with helper functions and state variables. However, the choice of a sequential regex substitution for parsing is a poor algorithmic choice for this problem, demonstrating a lack of understanding of its pitfalls. The list-handling logic is also quite convoluted.
Practical Value
Weight 15%The parser's incorrect handling of a common use case (nested inline styles) severely limits its practical value. It would not be reliable for converting real-world markdown documents.
Instruction Following
Weight 10%The solution adheres to all instructions in the prompt, including the function signature, the specific subset of Markdown to be supported, and the output format.