Possible change in Armstrong Numbers mentor notes

In the Armstrong Numbers mentor notes, this is a suggested piece of code:

def is_armstrong(number):
    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?

Specifically, this is the diff I’m proposing.

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.

But why would we say A or B when A includes B? Surely it’d be better to just say integers?

In any case, is the change for the function name valid?

EDIT: This too is wrong: we need to pull the para out of the code snippet.

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.

1 Like

Are we allowed to add mentoring notes now? If we are, I’d love to do one for Yacht - is that OK?

If it is, are they any general tips/documentation for mentor notes? Thanks!

You are ‘allowed’ as soon as you convince enough people, including the relevant maintainers, that your proposal of additional mentoring notes is a good one.

I have no a priori objection against adding more mentoring notes.

However, adding Dig Deeper material may be more efficient:

  • I expect Dig Deeper to be used by more people, in general.
  • As of now there have been only 238 mentoring requests for Yacht.
  • Not all – and quite possibly a minority – of the mentors use the mentoring notes.

Be mindful of the audience. Mentoring notes need to be useful to mentors.

Pass the proposed notes by experienced mentors and make sure they agree with your notes.

See also Mentoring Tips | Exercism's Docs.

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.

I think I’ll add Dig Deeper material, then.

1 Like

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. :slight_smile:

1 Like

That sounds good. Could you share the list?

Sadly, the forum has a 700 char line limit, so we’ll have to do a link to a google sheet.

This Sheet has one tab that shows exercises that don’t have approaches being worked on, the other shows exercises that don’t have mentor notes being worked on.

Where an exercise name appears, that is an existing or being-worked-on approach/mentor note.

Since I have to review these (and there may be others who also want to work on them) - I’d prefer if you limited yourself to 1-3 at a time for reserving/submitting PRs.