Enable strict=True for zip() where safe by Oll-iver · Pull Request #4547 · ManimCommunity/manim

all_arc_configs is either defined specifically by length of point_pairs or strictly forced to be the same length (n). In any case they'll always be the same length so strict=True works.

Oll-iver

committed

There should always be an equal amount of start and end anchors; radius_list is defined directly from the length of vertex_group; both outer_vertices and inner_vertices posess n vertices.

Oll-iver

committed

boundary_times always contains has an even length so both 'slices' in the zup function are the same length.

Oll-iver

committed

colors_in_gradient is defined to be the same length as p_list_complete; labels and parts are seemingly user inputs with no guarantee of equal length; val_range is defined to be same lenght as self.…

Oll-iver

committed

In most cases here, the tuples are either defined to be of same length or manipulated to be by the align_data function. In the match_points function there is currently no validation to ensure both …

Oll-iver

committed

Reverting _add_x_axis_labels() zip() function back

Oll-iver

committed

Reverted strict zip usage

Oll-iver

committed

color_gradient is defined to be same length as p_list_complete & within _add_x_axis_labels we define val_range to be the same length as self.bar_names

Oll-iver

committed

align_data and lock_matching_data have no validation to ensure tuples in the zip() function are of the same length. Every other time zip() is used here it is generally immediately manipulating or e…

Oll-iver

committed

All tuples in zip() functions here are either clearly the same size or manipulated to be the same size using the make_even function.

Oll-iver

committed

The tuples in the zip() function will clearly be of equal length, the second tuple is simply a cyclic shift of the first.

Oll-iver

committed

In the ingest_submobjects function arrays is a one to one mapping of attrs so they are guaranteed to have equal lengths.

Oll-iver

committed

Every usage of zip() consists of tuples that are either manipulated to be equal size or defined to be equal size.

Oll-iver

committed

the zip() function in bezier_remap will always consist of equal length tuples as current_number_of_curves is read directly from the shape of bezier_tuples and is used to dictate the size of split_f…

Oll-iver

committed

The zip() function color_gradient() will always consist of equal length tuples as floors is defined directly from alphas (which also defines alphas_mod1)

Oll-iver

committed

The tuples in the zip() function in adjacent_n_tuples will always be the same length so strict=True.

Oll-iver

committed

The find_intersection() contains a zip() function that has been set to strict=True. While it is technically possible to pass tuples to this function that are not the same length, this would resul…

Oll-iver

committed

Changed zip() function to have strict=True in init() as custom_labels is dependent on tick_range so guaranteed to have the same length.

Oll-iver

committed

Several instances of zip() set to strict=True. In add_coordinates we have axis manipulated to be the same length as tick_range. In get_riemann_rectangles() we have colors dependent on of x_range_Ar…

Oll-iver

committed

zip() function bool changed to strict=True in all these test cases. Most test cases either a) hardcode two things to be the same length, b) verify things are the same length before the function or …

Oll-iver

committed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Enable strict=True for zip() where safe #4547

Enable strict=True for zip() where safe #4547
behackl merged 25 commits intoManimCommunity:mainfrom
Oll-iver:strict-zip-fix

Commits on Jan 24, 2026

sub_alphas is derived directly from to_update so they're guaranteed to be of the same length.

self.shapes is initialised as a direct copy of the mobject, guaranteed to be of same length.

linspace in this case guarantees both arrays are of equal size (self.n_segments).

Any transformation already requires that each datapoint in the first tuple has a corresponding datapoint in the second (ie same length)

Replaced arange with linspace, eliminates risk of floating point errors and forces rgbas and offset to be the same size for strict=True

Commits on Jan 25, 2026

all_arc_configs is either defined specifically by length of point_pairs or strictly forced to be the same length (n). In any case they'll always be the same length so strict=True works.

There should always be an equal amount of start and end anchors; radius_list is defined directly from the length of vertex_group; both outer_vertices and inner_vertices posess n vertices.

boundary_times always contains has an even length so both 'slices' in the zup function are the same length.

colors_in_gradient is defined to be the same length as p_list_complete; labels and parts are seemingly user inputs with no guarantee of equal length; val_range is defined to be same lenght as self.…

In most cases here, the tuples are either defined to be of same length or manipulated to be by the align_data function. In the match_points function there is currently no validation to ensure both …

Reverting _add_x_axis_labels() zip() function back

Reverted strict zip usage

color_gradient is defined to be same length as p_list_complete & within _add_x_axis_labels we define val_range to be the same length as self.bar_names

align_data and lock_matching_data have no validation to ensure tuples in the zip() function are of the same length. Every other time zip() is used here it is generally immediately manipulating or e…

All tuples in zip() functions here are either clearly the same size or manipulated to be the same size using the make_even function.

The tuples in the zip() function will clearly be of equal length, the second tuple is simply a cyclic shift of the first.

In the ingest_submobjects function arrays is a one to one mapping of attrs so they are guaranteed to have equal lengths.

Every usage of zip() consists of tuples that are either manipulated to be equal size or defined to be equal size.

the zip() function in bezier_remap will always consist of equal length tuples as current_number_of_curves is read directly from the shape of bezier_tuples and is used to dictate the size of split_f…

The zip() function color_gradient() will always consist of equal length tuples as floors is defined directly from alphas (which also defines alphas_mod1)

The tuples in the zip() function in adjacent_n_tuples will always be the same length so strict=True.

The find_intersection() contains a zip() function that has been set to strict=True. While it is technically possible to pass tuples to this function that are not the same length, this would resul…

Changed zip() function to have strict=True in init() as custom_labels is dependent on tick_range so guaranteed to have the same length.

Several instances of zip() set to strict=True. In add_coordinates we have axis manipulated to be the same length as tick_range. In get_riemann_rectangles() we have colors dependent on of x_range_Ar…

zip() function bool changed to strict=True in all these test cases. Most test cases either a) hardcode two things to be the same length, b) verify things are the same length before the function or …