Castform form/variety mixup
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 5.4k
- Forks
- 1.2k
- Avg merge
- 2d 5h
- Merged PRs (30d)
- 21
Description
Hello PokéAPI team :)
I'm currently playing around with the API and looking at the underlying data with interest. I note already that there is a lot of discussion around forms and varieties (am working based on the explanation: https://github.com/PokeAPI/pokeapi/issues/401.
Castform (id 351) has 1 form on its Pokémon object, and on the species object (id 351) , there are four variations listed with Pokémon IDs: 351, 10013 (Sunny), 10014 (Rainy), 10015 (Snowy).
Then these Pokémon IDs have their own equivalent form (form IDs 10028 (Sunny), 10029 (Rainy), 10030 (Snowy).
However, on the species object, there is a form description:
'Form changes along with type to match the weather in battle, due to forecast. Castform is always in its normal form outside of battle, regardless of weather'
But considering that the field is called form_description, this would not be correct, since its changing to a different variation. (The actual language itself within the field form_description is using form colloquially, I guess?)
So is Castform meant to have forms (similar to Arceus), which seems to contradict the description given of what Pokémon forms are, is the field form_description incorrectly populated for this instance, or should there be a variety_description field instead/as well, or have I completely misunderstood.
Steps to Reproduce:
- Navigate to Pokémon endpoint with id 351 - only 1 form for Pokémon
- Navigate to species endpoint with id 351 - Form description field is actually describing the variety differences.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the Pokémon endpoint for ID 351 and the species endpoint for ID 351, then review the form and variety explanation in issue #401. Compare Castform's listed forms, varieties, and form_description to the project's intended model; done means reaching a maintainer-confirmed resolution for how this data should be represented.
Written by the indexing model from the issue text.
Assessment
- Domain
- api, backend
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100