Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Add support for multiple locale data generation #1052
What does this change
What was wrong
How this fixes it
Needless to say, there will be a performance penalty, and the severity of the penalty depends on:
The changes needed to ensure all tests will pass will most likely require backward-incompatible changes if the
The random generator related stuff can probably be proxied in a sane way like seeding the same value across all internal generators, but the others do not make as much sense like
We can name this proxy class something else to keep changes simple while still providing multiple locale support. I would like to know your thoughts on this @fcurella.
The flake8 errors are related to PR #1058. There is another error because
Other than that, I think the new
Single locale mode
In what I call multiple locale mode, attempting to proxy any
Instead, I think we should just leave it to users to subclass and create their own implementation if they really want to. After all, each of the internal
As for data generation, multiple locale mode will randomly choose a
Multiple locale mode
As for the locale strings I mentioned earlier, both
Would it still possible to seed the generator in multiple locale mode?
I think it should be consistent with what the constructor does. In other words, it should accept both, and normalize to
Yes but on an individual
If you really want a default implementation, we can probably proxy
Personally, I do not know if that will be a common enough use case, which is why I did not provide a proxy level implementation, and why I think it should be up to the users to subclass for their use cases.
the problem with called
Ideally, we want three ways to seed random values:
On that note, the proxy class can have a
So what are your thoughts?
Thank you for the clarification @malefice .
This is how I'm thinking it could work:
Yes, that is how
Yeah that is certainly possible, but I suggest raising a
Either way, doing this will definitely break any old code that calls
Old code that will break
So are you okay with this?
That's a much better idea! Let's do a
I'm comfortable with that, I think it's worth it for the additional features we gain and cleaner code.
As long as we increase the major version and have clear docs on how to migrate user's code, it should be fine.