fix(python): use datetime.date/time for date/time formats

[schani]

Bug

The Python generator mapped JSON Schema string formats date and time onto the same transformed-string kind as date-time. As a result, a schema property with format: "date" or format: "time" was typed as datetime.datetime and serialized with .isoformat(), so a date-only value like "2024-01-01" round-tripped as a full ISO datetime string (e.g. "2024-01-01T00:00:00"), which violates the input schema.

Repro:

node dist/index.js --lang python --src-lang schema example.schema.json

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "$ref": "#/definitions/Example",
  "definitions": {
    "Example": {
      "type": "object",
      "additionalProperties": false,
      "properties": {
        "d":  { "type": "string", "format": "date" },
        "t":  { "type": "string", "format": "time" },
        "dt": { "type": "string", "format": "date-time" }
      },
      "required": ["d","t","dt"]
    }
  }
}

Before the fix, d, t, and dt were all typed datetime. After the fix, d is datetime.date, t is datetime.time, and dt remains datetime.datetime.

Root cause

packages/quicktype-core/src/language/Python/language.ts folded the date and time TransformedStringTypeKinds into date-time in stringTypeMapping, so every downstream Python renderer switch only ever saw a single date-time kind.

Fix

• language.ts: keep date, time, and date-time as distinct kinds in stringTypeMapping instead of collapsing them.
• PythonRenderer.ts: emit datetime.date / datetime.time / datetime.datetime type names (via a new module-level import datetime helper) instead of always using datetime.datetime.
• JSONPythonRenderer.ts: add from_date/from_time parsing helpers (using dateutil.parser.parse(...).date() / .time(), with a format-shape assertion) alongside the existing from_datetime, and route the date/time/date-time transformer cases to the correct converter for both parsing and .isoformat() serialization.

Test coverage

test/fixtures/python/main.py (the Python fixture driver used by end-to-end schema fixture tests) was strengthened to assert the correct runtime types (datetime.date, datetime.time, datetime.datetime) whenever the round-tripped object has date/time/date-time properties. This is exercised by the existing test/inputs/schema/date-time.schema fixture (which already has date, time, and date-time properties plus union-array cases), run via the standard schema-python fixture suite — no fixture wiring changes were needed since the schema/inputs already existed, they just weren't checking runtime types before.

Verification (local)

• npm run build passes.
• npm run test:unit: 163/163 tests pass.
• QUICKTEST=true FIXTURE=schema-python script/test: all 67 tests pass, including date-time.schema with the strengthened runtime-type assertions.
• Manually re-ran the repro from the issue: generated code now emits datetime.date/datetime.time/datetime.datetime as expected, and a manual round-trip in Python confirms to_dict() now serializes d as "2024-01-01" and t as a time-only ISO string instead of a full datetime string.
• CI will additionally validate the other language fixtures are unaffected.

Fixes #1974

🤖 Generated with Claude Code