[Making the Grade] Union return type in Task 6

https://github.com/exercism/python/blob/650a597311104f94f5c807a68c7859e16dc76327/exercises/concept/making-the-grade/loops.py#L51

IMO the union return type is not needed in a concept exercise. Besides, I don’t see the value it provides at all in the current setting because <student name> is the only unique part that is matched.

My suggestion is to have a str return type, i.e.:

    :return: str - name of the first student with a perfect score or 'No perfect score.' if not found.

Happy to submit a PR.

[pranasziaukas]

I expect to pick this right after #2668 is merged (or dismissed).

[BethanyG]

No @pranasziaukas – I don’t think you are overthinking it. (Perhaps I was when making the exercise & deciding to include nested data structures…but that’s a wholly different story…) 😄

I think the real problem is that there aren’t strong standards or practices around this. Python is dynamically/duck typed, and functions return objects, typing TBD. There are conventions (and hints), and they vary by programmer, team and project. It’s an architecture and design discussion. That doesn’t mean I am arguing for arbitrary multi-return types – just that the concern is most often in a context of how an overall program or application is built and used.

So I don’t really think it is a big deal to have type mis-match here where the code is isolated and focused on a specific concept like loops. And yes, that probably makes me a naughty Pythonista. 😄

TL;DR I can certainly live with changing it to

:return: first `[<student name>, 100]` or `[]` if not found.

and might even propose that it be amended somewhat to: :return: first `[<student name>, 100]` or `[]` if no student score of 100 is found.

Let’s just make sure that the instructions, examples, docstrings, et. al. are checked to make sure that the change is clear to students.

And thank you both for discussing this. 💜