New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use custom ParserError class in parser exceptions #881
Conversation
There was a similar issue in @jbrockmendel Do you remember what happened with the plan to switch these class ParserError(ValueError):
def __repr__(self):
if len(self.args) > 1:
return self.__class__.name + ": " + (self.args[0] % self.args[1:])
else:
return super(ParserError, self).__repr__() Then we can have our cake and eat it, too. |
Nothing comes to mind. I've been going through older issues/PRs, will mention if I come across it |
@pganssle @jbrockmendel : Friendly ping here. Any more thoughts on this one? |
LGTM. @pganssle go for it? |
@jbrockmendel I keep going back and forth on this because I do think it might be useful for someone to be able to extract the I'm leaning more towards the solution of switching these from |
@pganssle : Should the error be defined in the same file, or is there a better place for it?
From the perspective of a maintainer, I find this argument a little nebulous for using |
@gfyoung Well, the thing is I generally don't want to make any guarantees about the contents of an error message, which is why I don't generally test with any sort of regex match on the errors. The reason is that I don't consider that format part of the public interface. I would be more comfortable with the idea that Given that there is a way to both make the error look nice when printed and make |
@gfyoung Ah, missed the question, I think same file is best, and you can add it to |
@pganssle : I had to make some adjustments to your suggested PTAL. |
@pganssle @jbrockmendel : Friendly ping here. Any more thoughts on this one? |
@pganssle @jbrockmendel : Another friendly ping here. Any more thoughts on this one? |
@pganssle call the ball |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm very sorry that I've been remiss about merging this. I have noted two minor changes that need to be made, but I have done this primarily for my own notes, since I can simply make the required changes myself as part of the merge.
I can update and merge this tomorrow or the next day. Feel free to ping again if I don't have it done by Tuesday.
No worries. I'm no stranger to the time crunch that maintainers can have 🙂
Sounds good. I'll ping on Tuesday if necessary. Thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I made the required changes, added a test and then changed the tests to check against ParserError
rather than ValueError
.
Hm.. Build failure looks unrelated. We can merge this one after the tz master build is fixed. |
This gives a nicer string representation while retaining access to the input string in the exception arguments.
Ensures that ValueErrors raised when building the datetime from an already-parsed string will be raised as ParserError as well.
ParserError is a subclass of ValueError, so this just makes the tests stricter, and this can be considered a backwards-compatible change.
If multiple arguments are passed in, it raises a tuple, not one string.
xref pandas-dev/pandas#25430 (comment)