What we are looking for is a docstring for the class, like the one for AxisError.

@Radhika14soni are you planning to update this PR with the change requested by @mattip?

Gentle ping, @Radhika14soni . Do you need help with moving this forward?

Hello there, @melissawm and @Radhika14soni, nice to meet you! I would like to help with moving this PR forward.

Hello there, @Radhika14soni. I believe it is important to emphasize that I am also a complete new contributor to numpy community and hopefully will have the chance to grow together with you and all the amazing team.

Let's start, I followed a discussion on Dec 17, 2020, where there was a proposal to get the issue done by analyzing the docstrings as implemented for the other exceptions classes at the same file.

You have proposed the following change

class TooHardError(RuntimeError):
    def __str__(self):
        return ("max_work Exceeded")

For the original code

class TooHardError(RuntimeError):
    pass

Taking a look at others __str__ I could notice a pattern including a string literal as the first statement and adding more information with format feature. Like what I see here [ * ]

def __str__(self):
        # only show the number if more than one input exists
        i_str = "{} ".format(self.in_i) if self.ufunc.nin != 1 else ""

Hope to hear from you soon,
Best regards

We are looking for the class __docstring__, more than the __str__ repr of the class. Taking an example from AxisError, that docstring is rendered in the documentation to describe when this error appears and how to mitigate it. The __docstring__ for TooHardError is much simpler. A good idea of why it is raised can be seen in the documentation for shares_memory.

@mattip and @InessaPawson First, my apologies for the slow reply.
Understanding the process involved in contribution has been a little massive.

Now, a few questions.

1. Should I move the work to a fork that is a version of mine or I am expected to commit and continue doing the code on Radhika14soni`s fork?
2. Reading the docs I learned that we need to create branches names more related to the issue as possible, I believe that the current name is not as expected. So, again, am I expected to do something about it?
3. @mattip I was ok following the instructions from AxisError however, when trying to extract more information in order to add Attributes, Parameters, Examples and so on into docs I tried checking out that source link that you gave me for the rendered documentation and then I was not able to find anything related with AxisError. Did I miss something ?

Finally, I am writing something more like this, still working on the information on how to mitigate it:

    """max_work was exceeded.

    This is raised whenever the maximum number of candidate solutions to consider specified by the ``max_work`` parameter exceeds.
    Since checking whether two arrays share memory is NP-complete you have may considered 
    setting up max_work to a finite number avoiding the function to become exponentially slow for some inputs.

    """

Do you think it's all right to do it?

Best Regards,

(1) and (2): I think you can restart this on your own fork, with any branch name you choose.

(3) This exception does not really need all those sections. Let's start with just the docstring and see where we go from there. The string you have looks like a good start.

The task has been completed in #21471. We can close this pull request.