adjusting overload of fractions.Fraction.__new__
#13241
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The existing overload has two issues, from stubtest's point of view. One is mixing up pos-only and kw-or-pos parameters between different branches of the overload (My MR python/mypy#18287 addresses that issue) and the other is the name of the parameters changing between overloads. (My MR would not fix that. stubtest currently tracks each parameter either by name or by position if it thinks it's pos-only. I think that handling this properly would require stubtest to track all parameters by both name and position, and make a decision about which one is relevant later in the process of signature generation, a much more complicated proposition.)
At any rate, "value" here is a fictional parameter name: it does not appear in the implementation anywhere. I looked in the history, and "value" appeared in the original version of
fractions.pyi
. I didn't see any particular discussion about it at any point.I assume the idea was to add clarity; the documentation does a similar thing with parameter names of this class. I'm not familiar with the extended world of tools that consume typeshed, so this MR is less of a "we should definitely do this" on my part, and more of a "Let's have a discussion about it". This version is accurate to runtime. Does someone know how much this might affect the kinds of tooling that take typeshed as a source of documentation?
I think that "numerator" is technically correct even in the single argument form, if we assume a denominator of 1 in those cases. A fraction of (for example)
0.5/1
is valid, and "normalize the fraction 0.5/1" is an equivalent operation to "give me the fraction that corresponds to the value 0.5". So while value has more clarity, I don't think that numerator is outright wrong. That might not help much though.