This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author mark.dickinson
Recipients Katherine Michel, docs@python, mark.dickinson
Date 2020-02-11.07:20:19
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Hi Katherine,

My report was really just about the last sentence, but I agree that the "narrower" language is confusing here. If someone says that a type "A" is narrower than type "B", that suggests to my ears that "A" represents a subset of the values of "B" (but conversely, that "B" can represent everything "A" can). That applies to the float/complex pair, or to Python 2's int/long, or to NumPy's float32/float64 or int32/int64, but not really to int/float, since int has many values that can't be represented as a float (and even has larger range than float).

I suspect that the wording may have made a bit (but only a bit) more sense in Python 2, where `long` was still in the mix, and `int` was the fixed-width type, which really would have been a subset of `float` on a typical 32-bit machine.

So yes, if we can find a way to ditch the "narrower" language altogether but still convey that idea of implicit conversions from int to float, and from float to complex, that would be good.

And then the last sentence still needs fixing somehow.
Date User Action Args
2020-02-11 07:20:20mark.dickinsonsetrecipients: + mark.dickinson, docs@python, Katherine Michel
2020-02-11 07:20:20mark.dickinsonsetmessageid: <>
2020-02-11 07:20:20mark.dickinsonlinkissue39530 messages
2020-02-11 07:20:19mark.dickinsoncreate