Skip to content

Conversation

@amureki
Copy link
Contributor

@amureki amureki commented Apr 14, 2018

This fixes an edge case for decimal parsing.
When we are receiving Nan or infinite value in _to_decimal (which theoretically should not be possible), we are raising a ValueError, instead of continuing with it.

Thank you @pganssle for the suggestion, please, check if this solution fits well.

if not decimal_value.is_finite():
raise ValueError("Converted decimal value is infinite or NaN")

return decimal_value
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's preferable to put the return statement outside the try/except block.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pganssle thanks for a fast review!
I think, it would be better to put it into else statement, meaning that the code

must be executed if the try clause does not raise an exception

Then we would not have variable referenced before assignment warning.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good.

@pganssle
Copy link
Member

pganssle commented Apr 14, 2018

Can you add a change to the changelog? See CONTRIBUTING.md, you'll want to add changelog.d/679.bugfix.rst.

Also, please add yourself to the AUTHORS.md file, make sure your name is marked D since you are contributing after the dual license is in effect. Names are in alphabetical order.

@pganssle
Copy link
Member

Looks perfect! Will merge when tests pass. Thanks so much for the report and bugfix!

@amureki
Copy link
Contributor Author

amureki commented Apr 14, 2018

@pganssle thank you for checking this out so quickly and for all your suggestions, that is very pleasant and important!
This is a very good job as a project maintainer, I would say.

@pganssle
Copy link
Member

@amureki Thanks for your kind words, and I'm glad you had a good experience contributing to dateutil!

@pganssle pganssle merged commit e6644a4 into dateutil:master Apr 14, 2018
@amureki
Copy link
Contributor Author

amureki commented Apr 23, 2018

@pganssle hello!

Would you, please, update me on the release process? How often do we do this, what are the prerequisites for it? I would love to see the new version released. :)

@pganssle pganssle added this to the 2.7.3 milestone Apr 23, 2018
@pganssle
Copy link
Member

Releases happen every once in a while when I have time to make one. I'm trying to get better about making frequent releases. I'd like to get #700 merged first, and generally wrap up everything in the 2.7.3 milestone.

Additionally, I'm thinking that the already-merged #672 will actually be a performance regression without implementing #691, so I'm planning on creating a new 2.7.x branch for future patch releases.

@amureki
Copy link
Contributor Author

amureki commented Apr 23, 2018

Oh, thank you for the detailed explanation of the release process!
Of course, there is no hurry for us, but I did not found any, that's why I asked.

@pganssle pganssle mentioned this pull request May 9, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants