Closed vallode closed 2 years ago
This is certainly an interesting idea that lends itself quite well with python being a dynamically typed language. However the potential downside I see is that MethodGenerator
in this case could become a generator that does everything, the only limit would be the imagination of the person using it (for good and bad).
I personally don't mind a UUID generator that simply wraps uuid.uuid4()
(or any of the other uuid versions) as the purpose and result of such a generator is intuitive and easily understood.
That being said, I'm definitely open for discussion here. Are there other usecases for this?
The reason I think MethodGenerator
is a decent solution is because currently Faker
relies on any attribute input to contain the generate
method, this means that if you ever run into a situation that does not have a generator, you'll have to create one yourself. I think there needs to be a better solution for that, potentially just allowing faker to accept functions themselves.
I'll get around to making a merge request for a UUID generator, I think there are a lot of projects using UUIDs for their PKs.
Other usecases, off the top of my head:
Anything else I can think of pretty nicely falls into the String
generator, which can be used for a ton of things. Though it might be nice to have helper generators that do things like phone numbers etc.
Currently in a project of mine I am subclassing the generator object:
Seeing as a standalone UUID generator isn't exactly necessary here, it would be nice to be able to pass methods to a generic generator like:
This would be called like: