Summary

Playground

Example code:

dict((
    ('0', 0),
    ('1', 1),
    ('2', 2),
    ('3', 3),
    ('4', 4),
    ('5', 5),
    ('6', 6),
    ('7', 7),
    ('8', 8),
    ('9', 9),
    ('10', 10),
    ('11', 11),
    ('12', 12),
    ('13', 13),
    ('14', 14),
    ('15', 15),
    ('16', 16),
    ('17', 17),
    ('18', 18),
    # ('19', 19),
    # ('20', 20),
    # ('21', 21),
    # ('22', 22),
    # ('23', 23),
    # ('24', 24),
    # ('25', 25),
    # ('26', 26),
    # ('27', 27),
    # ('28', 28),
    # ('29', 29),
))

The time it takes for ty to check this code (and the memory it uses) seems to grow exponentially with the number of elements in the tuple. The code above (with 19 elements) takes about 350 ms to check on my PC, then it gets doubled each time I uncomment one more element in the tuple.

I should add that I do realize that storing an arbitrary number of elements of the same type is not what tuples are meant to be used for. In my case it was an old project where tuples were utilized as "read-only lists", and a tuple of 31 elements was enough to get ty OOM-killed.

Version

ty 0.0.21