Refactor turtle internals behind backend adapters and add headless recording backend tests

[Copilot]

• Fetch and identify origin/master (the actual upstream with PEP 810 lazy import syntax)
• Merge origin/master into branch; resolve single conflict in _iscolorstring (keep backend abstraction)
• Apply PEP 810 explicit lazy imports in turtle.py:
  • Replace TK = None sentinel + inline import tkinter as TK with lazy import tkinter as TK at module level
  • Add lazy from tkinter import simpledialog at module level; remove inline from tkinter import simpledialog
  • Simplify _init_tk(): use _TK_INITIALIZED = False flag, remove internal import tkinter as TK
  • Remove inline import tkinter as TK from is_color, blank_image, load_image methods
  • Simplify __getattr__ (TK no longer needs lazy trigger via it)

Original prompt

Create a draft pull request against repository m-aciek/cpython (base branch: main) that refactors Lib/turtle.py to support multiple rendering backends with a minimal-diff, SVG-friendly interface approach.

Goals

• Preserve turtle’s public API and default behavior (Tkinter remains the default backend).
• Reduce direct coupling to tkinter Canvas by routing drawing, timers, and event wiring through a backend adapter interface.
• Keep changes incremental/minimal in terms of behavior, while designing the backend interface to be SVG-friendly (retained-mode), not a 1:1 copy of Tk Canvas.
• Add a headless/recording backend suitable for unit tests (no GUI required).

Deliverables

1. Backend interface scaffolding

• Introduce internal backend abstractions (e.g., _TurtleBackend, _Renderer, _EventLoop; naming up to you but keep them private) either within Lib/turtle.py or as an internal module under Lib/turtle/ (prefer minimal disruption).
• The interface should support these operations at minimum:
  • draw_polyline(points, style) -> handle
  • draw_polygon(points, style) -> handle
  • draw_text(x, y, text, style) -> handle
  • update_geometry(handle, points) and/or update_style(handle, style) (optional but support current behavior)
  • delete(handle), clear()
  • set_background(color)
  • set_world_coordinates / transform mapping hooks as needed
  • flush() (can be no-op for Tk)
  • timer scheduling: call_later(ms, callback)
  • event bindings: mouse click/drag/release and key press/release hooks sufficient to support existing turtle Screen methods

2. Tk backend implementation

• Implement a Tk backend adapter that uses tkinter Canvas internally and satisfies the new interface.
• Ensure existing features (tracer/update, onclick/ondrag, onkey) continue to work.
• Ensure done()/mainloop semantics remain backward compatible.

3. Headless backend

• Implement a pure-Python recording backend that records draw operations into a list.
• Use it in tests to validate core drawing semantics without Tk.

4. Tests

• Add unit tests under Lib/test/ (or appropriate location) that:
  • Instantiate turtle with the headless backend (provide an internal hook to inject backend; do not add a new public API unless absolutely necessary).
  • Verify that basic turtle commands (forward, left/right, penup/pendown, pencolor, pensize, begin_fill/end_fill for a simple polygon) produce expected recorded operations.

Constraints

• Keep the refactor minimal: avoid large-scale re-architecture; focus on introducing an internal adapter boundary.
• Avoid adding third-party dependencies.
• Do not implement the SVG backend itself; only make turtle ready for it.

Notes

• The interface should be SVG-friendly: it should not require Tk-only concepts (e.g., PhotoImage, itemconfig semantics) as the core dependency.
• Where turtle currently relies on item IDs and mutation, provide a thin compatibility layer (handles) that can map to DOM nodes in a future SVG backend.

Please include in the PR:

• Code changes
• New tests
• A PR description summarizing the approach and how to build confidence (how tests cover it).

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: how could cpython's turtle be changed to handle more canvases (beyond tkinter) implementations more gracefully?

Assistant: CPython’s turtle is historically Tkinter-first: it directly assumes a Tk Canvas/Tk event loop in a lot of places, which makes “drop in a different canvas” hard. To support additional canvas implementations (Qt, wx, web/canvas, pygame, etc.) more gracefully, the cleanest direction is to turn turtle into a small, stable “turtle engine” plus pluggable backends.

Here are concrete, CPython-friendly changes that would get you there.

1) Define an explicit backend interface (protocol) instead of “Tk objects”

Create an internal module (e.g. turtle._backend) that defines the minimum set of operations the turtle engine needs. For example:

• Drawing primitives
  • create_line(points, **style), create_polygon(points, **style), create_text(x, y, text, **style)
  • delete(item_id), clear()
  • set_background(color|image)
• Coordinate + transform helpers
  • world_to_screen(x, y) and screen_to_world(x, y) (or a single transform object)
• Timing / animation
  • ontimer(callback, ms)
  • “batching” hooks: begin_frame() / end_frame() or flush()
• Events
  • bind_mouse(button, handler), bind_key(key, handler), bind_resize(handler)
• Lifecycle
  • mainloop() (or return control to host loop), close()

Then refactor turtle.Screen / TurtleScreen so it talks only to that interface—not to a Tk Canvas.

Why this helps: every other UI toolkit can implement one adapter without patching turtle internals.

2) Split “model/state” from “rendering”

Right now, turtle mixes:

• turtle state (pos, heading, pen state, shapes, undo buffer)
• screen state (world coordinates,...

This pull request was created from Copilot chat.