Tech Stack
Overview
This contribution focused on a real bug inside Plotly.py’s autoshape helpers: labeled vertical lines on datetime axes could crash because the library tried to compute annotation placement with arithmetic that did not generalize beyond numeric coordinates.
The deeper architectural issue was that Plotly.py was manually building annotations for shapes even though Plotly.js already supports labels natively through shape.label. Moving toward that path makes the behavior more robust, more consistent across axis types, and less dependent on fragile placement logic.
Focus
- Reproducing the datetime-axis crash triggered by
add_vline(x="2020-09-24", annotation_text="Test"). - Tracing the call path through Plotly.py’s autoshape helpers and internal annotation logic.
- Refactoring labeled shapes toward
shape.labelinstead of manual annotation placement. - Preserving compatibility while preparing the code and tests for a cleaner long-term migration.
What I Changed
- Worked on the issue around refactoring
add_vline(),add_hline(),add_vrect(), andadd_hrect()to use Plotly.jsshape.label. - Built a compatibility helper to map legacy
annotation_*kwargs into shape label fields safely. - Updated the internal autoshape processing path so labeled vertical lines no longer crash on datetime axes.
- Opened a draft PR while the codebase remained in a transition phase between legacy annotations and native labels.
Why it matters
This work was valuable not just because of one bug fix, but because it touched the boundary between Plotly.py and Plotly.js. It was a good example of how wrapper libraries can drift into duplicated abstractions, and how aligning them back to the underlying platform can remove subtle user-facing failures.