[Sskift]

Summary

Two separately parsed documents containing the same NaN value compare both equal and unequal:

left = tomlkit.parse("value = nan")
right = tomlkit.parse("value = nan")
left == right  # True
left != right  # True before this change

Container.__eq__ already treats matching NaNs as equal, including those nested in arrays. Add the corresponding inequality method so != follows that existing document comparison policy. Unsupported operands still return NotImplemented, allowing reflected comparisons.

Validation on Windows / CPython 3.12.10: four new cases fail and six controls pass against the original source; all 102 document tests and all 1,234 tests pass with the fix. Ruff lint/format and git diff --check pass. Mypy reports the same 33 baseline diagnostics. A separate Codex agent independently checked the red/green tests, 768 comparison cases, and reflected/subclass comparison controls.

Duplicate Check

• I searched the open PRs and found none that already fixes this issue.
• Related open PRs: Targeted NaN searches returned literal parsing, rounding, and numeric fallback changes; none changes document inequality.

Agent Drafting Metadata

• Agent: OpenAI Codex
• Model: Exact model identifier was not exposed to this worker.
• Notes: Codex assisted investigation, implementation, tests, and this description. Independent review was performed by another AI agent; no human review is claimed.

[dimbleby]

surely this is fixing in the wrong direction, making tomlkit behaviour the exact opposite of regular python comparison for NaN values?

[Sskift]

Thanks for raising this. Python's ordinary NaN equality is indeed different. This patch follows the policy already implemented by Container.__eq__, which calls _equal_with_nan: two separately parsed value = nan documents currently compare both equal and unequal. It only makes != consistent with that existing == result.

Would you prefer document equality itself to follow Python's NaN semantics instead? That would require changing __eq__ and its existing NaN behavior as well. It would be useful to settle that direction before updating this branch to resolve its current conflict.

[frostming]

I suggest moving this implementation of __ne__ into the common base class in _types.py.