Use tuple instead of string for (LOWER|UPPER)_TABLEs.

[ttsugriy]

This avoids unnecessary join and speeds up translation.

You can see benchmarks and memory measurements in the colab.

The summary:

%timeit "".join(_all_chars[:97] + _ascii_upper + _all_chars[97+26:])
3.25 µs ± 120 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)

vs

%timeit _all_chars[:97] + _ascii_upper + _all_chars[97+26:]
1.37 µs ± 234 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

which reduces import time and

%timeit english_upper('ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789_')
1.08 µs ± 227 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

vs

%timeit english_upper2('ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789_')
872 ns ± 6.37 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

which suggests more than 10% faster english_upper runtime perf. The cons of this approach are potentially breaking change if anyone clients rely on these constants to be strs (but I couldn't find any usages on github or by googling) and tuple uses more memory - 2088 vs 329.

[MatteoRaso]

LGTM. Thanks!

The cons of this approach are potentially breaking change if anyone clients rely on these constants to be strs

I don't think this will be a problem, since these constants are only meant for internal use.

[charris]

Thanks @ttsugriy .