In the Armstrong Numbers mentor notes, this is a suggested piece of code:
count = len(str(number))
total = sum(int(digit) ** count for digit in str(number))
return number == total
Here, str(number) is repeated twice - would this be counted as being against the principle of DRY? I myself extracted this into a separate variable str_num. Should we implement this change in both occurrences of this issue in the mentor notes?
I’ve also realized that the function naming is wrong: the mentor notes say is_armstrong, while the tests and the stub file use is_armstrong_number. I’ve updated the diff to reflect this.
The mentor notes also say: “The problem requires the student to sum each digit of an integer or natural number raised to the number of digits’ power.”… by the very definition, integers aren’t natural numbers. Perhaps this ought to be changed - or am I just being pedantic? So that’s three proposed changes - two which are in the GH diff, and the third I’m not sure how to update it.
Maybe. But rules are meant to be broken. Calling str() twice isn’t a big deal and many people may prefer that over defining a new variable. Neither is objectively correct or incorrect. As such, I would defer to the preference of the original author and not impose arbitrary requirements on the notes.
The “or” can be interpreted as "this object or that object*, ie listing two distinct objects and not suggesting they are the same.
Probably. These are notes to give mentors an idea of what a good solution looks like and what to discuss. Mentors read these and then type up their own thoughts. These notes don’t need to be exacting in their language.
Yeah. Feel free to rename the function. I don’t think it’s a big deal either way. The function demonstrates a good approach, regardless of the name. The snippet isn’t designed to be tests so it’s not “broken” (and may have been correct at the time of writing). Feel free to fix the formatting, too. But there’s much higher value in, say, adding mentoring notes to exercises that don’t have one over minor cosmetic corrections to existing notes.
I am going to re-enforce this from Matthijs – mentor notes need to be useful for mentors, and be for exercises where there are both a lot of mentoring requests, and a lot of room for different approaches and strategies in crafting solutions.
Yacht (as community solutions show) has about two represented answers, so unless your mentor notes outline other approaches or other considerations for enriching/explaining/streamlining those strategies, they are not likely to be very helpful for mentoring.
I’d also like to call out this from IsaacG. Minor and cosmetic changes are much lower value (and also burn reviewer and maintainer time). Far better to think about new and useful mentor notes, or adding new considerations, resources, or other useful points for mentors.
For Python, please check with me first on which exercises. We’ve actually divided up the list among several contributors who are working on things and they may or may not have submitted their draft PRs yet. I can give you a list of those that are not yet being worked on.