Roll our own generate_string() because mimesis' has gone away

[shwina]

Starting mimesis=9.0.0, the generate_string function has become private:

In [1]: import mimesis

In [2]: mimesis.__version__
Out[2]: '9.0.0'

In [3]: mimesis.random.random.generate_string
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
Cell In[3], line 1
----> 1 mimesis.random.random.generate_string

AttributeError: 'Random' object has no attribute 'generate_string'

In [4]: mimesis.random.random._generate_string
Out[4]: <bound method Random._generate_string of <mimesis.random.Random object at 0x555992f65a20>>

This PR replaces all uses of the function with a homespun one. Note that the implementation is about as fast (perhaps identical?)

In [6]: %timeit "".join(random.choices(string.printable, k=100))
9.25 µs ± 98.3 ns per loop (mean ± std. dev. of 7 runs, 100,000 loops each)

In [7]: %timeit mimesis.random.random._generate_string(string.printable, 100)
9.62 µs ± 103 ns per loop (mean ± std. dev. of 7 runs, 100,000 loops each)

[bdice]

@shwina Great news! I think this means we can drop the mimesis dependency entirely. Can you do that in this PR?

[bdice]

Note: We may also need to drop this pinning from the integration repository.

[shwina]

@bdice it looks like there are some non-trivial uses for mimesis in our code base (see for example

cudf/python/cudf/cudf/tests/test_parquet.py

Line 464 in f27be56

generator=lambda g: [g.address.city() for _ in range(40)],

) that I don't think we can drop it as a dependency.

[bdice]

@shwina Thanks for noting the nontrivial uses of mimesis. I hadn't caught those when reading before because it isn't directly calling mimesis, it's going through some kind of generator API.

However, I wonder if we could move towards cutting those features from our code... it doesn't seem particularly important to have a "city name generator" as a dependency in cudf.

[ttnghia]

/merge