feat: fallback front_female sprite to front_default for female-only p…

[programgames]

Changes description

A simple solution for the #271 .
If the request if a simple GET for the pokemon, we select the specie and check if the gender rate is only female.
In this case we copy the valuer from default to female sprites with this mapping :

_FEMALE_FALLBACKS = {
    "front_female": "front_default",
    "back_female": "back_default",
    "front_shiny_female": "front_shiny",
    "back_shiny_female": "back_shiny",
}

PS : I would like to know if Pokemon.objects.all().select_related("pokemon_species") could be a performance problem on the server, Should I test performance before and after this change to compare ?

[Naramsim]

Very interesting implementation. Can I ask what's the purpose of this function? It's for having ready at hand some data later on in the serializer.py part?

[phalt]

I'm strongly of the opinion that the data should just be shared with PokeAPI and consumers should handle this themselves.

[Naramsim]

Among the years we always pulled data from veekun which in turn got it from decompilations. The data was sometimes pretty cryptic to use. I can mention the use of rare Unicode characters, having braces in strings that acted as templates, having hidden characters and so on. In the beginning we were reluctant to change these pieces of data turning to the users to implement custom strategies.

Eventually we cleaned the garbage that we were serving and everyone was happier. Maybe valuing user-friendliness over strict data rules was the key to it.

That said I'm in favour of these kind of changes. If a pokemon has a 100% female rate then the female_sprite can be inferred to be the same as the default_sprite. In this case default_sprite and female_sprite coincide. By having the female_sprite filled in (by this custom logic or any other method) is ok with me.