It would be nice if some math people (like @mdickinson, or @rhettinger, or @tim-one, or @skrah) take a look at it.

I'll give this a thorough review when I get a chance. Off-hand, it looks like an aggressive edit.

I am not sure that they can be considered legacy methods. They are useful if you want to restrict the type of the input. I even proposed to add alternate restricted constructors for other numeric types (for example see #26827).

I am not sure that they can be considered legacy methods. They are useful if you want to restrict the type of the input. I even proposed to add alternate restricted constructors for other numeric types (for example see #26827).

I'm happy to remove the notes I added in 8f537ea, but I'll defer to you and @mdickinson on whether that's a good idea or not :)

I am not sure that they can be considered legacy methods. They are useful if you want to restrict the type of the input.

I definitely see a case for restricting to numeric input (as opposed to str or bytes, for example), but that's not quite what from_float does, or what it was intended for. from_float is legacy in the sense that it was originally introduced to make float-to-decimal conversions possible at at time when it had been decided to make Decimal(2.3) an error. That restriction was later relaxed, making from_float largely redundant.

Off-hand, it looks like an aggressive edit.

I'm in favour of having the information about the danger of Decimal(1.2) in the documentation for the main Decimal constructor instead of in the documentation of from_float, where it's less easy to notice. The error seems to be common - it turns up repeatedly in Stack Overflow questions, for example.

I'm happy to remove the notes I added in 8f537ea

That may be simplest for this PR.

I am not sure that they can be considered legacy methods. They are useful if you want to restrict the type of the input. I even proposed to add alternate restricted constructors for other numeric types (for example see #26827).

I've reverted the addition of the notes saying that they are legacy methods (cc. @serhiy-storchaka).

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

And if you don't make the requested changes, you will be put in the comfy chair!

Thanks all for the reviews! I feel like I've received slightly contradictory feedback on this, and it was certainly never my intent to make an aggressive edit, so I've reduced the PR down to a minimal diff which should hopefully be less controversial.

I have made the requested changes; please review again.

Thanks for making the requested changes!

@serhiy-storchaka, @mdickinson, @rhettinger: please review the changes made to this pull request.

I feel like I've received slightly contradictory feedback on this

Agreed. Raymond's assigned this to himself, so I'll duck out at this point and leave this to you and him.

@rhettinger, is there anything more you'd like me to do here? :)

(I don't have merge privileges; I'm only a triager.)