⚠️ Potential issue | 🟠 Major

Incomplete default value handling makes the function only partially functional.

The default_value parameter is accepted but completely ignored—both branches return the same awaitable regardless of whether a default is provided. This causes the function to fail the second use case described in the PR objectives: when the async iterator is exhausted and a default value is provided, RustPython raises StopAsyncIteration instead of returning the default like CPython does.

While the TODO comment acknowledges this limitation, having a function signature that accepts a parameter it cannot honor is problematic because:

• Users expect CPython-compatible behavior
• The silent acceptance of default_value creates a false sense of functionality
• It's better to fail fast than fail silently

Consider one of these approaches before merging:

Option 1 (preferred if feasible): Complete the implementation by adding PyAnextAwaitable to wrap the awaitable and handle the default value case.

Option 2: Reject the default parameter explicitly until support is implemented:

 #[pyfunction]
 fn anext(
     aiter: PyObjectRef,
     default_value: OptionalArg<PyObjectRef>,
     vm: &VirtualMachine,
 ) -> PyResult {
     let awaitable = vm.call_method(&aiter, "__anext__", ())?;
 
-    if default_value.is_missing() {
-        Ok(awaitable)
-    } else {
-        // TODO: Implement CPython like PyAnextAwaitable to properly handle the default value.
-        Ok(awaitable)
+    if let OptionalArg::Present(_) = default_value {
+        Err(vm.new_not_implemented_error(
+            "anext() with default value is not yet implemented".to_owned()
+        ))
+    } else {
+        Ok(awaitable)
     }
 }

Option 3: Defer merging this PR until the default value handling is fully implemented.