I did try to make iter_segments work first. But I found that here (and#16859, and upcoming PR on center of mass), I kept repeating this logic across each function I wrote so that I could get all the control points of each curve, so I went ahead and added this generator.

A problem is that naively you'd thing the difference between iter_segments and iter_curves is that one returns segments and the other returns curves, but actually it's something completely different: one excludes the start point of each segment/curve and the other includes it. So should this instead be a kwarg to iter_segments, e.g.include_starts?

I'm happy to make this a private helper method that is called byiter_segments when the parameterinclude_starts is passed, but I worry about bloatingiter_segments with a bunch of options.

Especially because it'sreally obnoxious that.iter_segments() returns aflattened sequence of coordinate pairs, so in order to create the desired API (more importantly to not doom anyone using this code in the future to a lifetime ofreshape calls), I'd have to add another parameter as wellflattened=False which determines whether to flatten the (naturally (N,2)-shaped) array of control points before returning it.

Oh, and currently,.iter_segments() returns a vertex that we're supposed to be ignoring (CLOSEPOLY) instead of correctly returning the first vertex of that stroke.

This is almost certainly a bug, but would probably want its own PR.

Adding the CLOSEPOLY bugfix,include_starts andflatten_vertices toiter_segments instead of just making a separateiter_curves makes the code significantly noisier, but if that's not as big of a priority as minimizing new API surface, I'm happy to do that.

Pushed up a new version where the generator yields BezierSegments and is namediter_bezier. I think this solves the problem that you (correctly) pointed out of the name.iter_curves not being intuitive, along with preventing me from having to make multiple, significant modifications toiter_segments.