← 输入框|bugs.python.org|刷新

➜

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.

作者 mark.dickinson
收信人 josh.r, mamrhein, mark.dickinson
日期 2021-07-02.11:42:00
SpamBayes Score -1.0
Marked as misclassified 是
Message-id <1625226121.04.0.567882853241.issue44547@roundup.psfhosted.org>
In-reply-to
内容
I'm actually struggling to think of situations where typing.SupportsInt would be useful in its current form: if I'm writing a function that wants to do a duck-typed acceptance of integer-like things (for example because I want my function to work with NumPy integers as well as plain old Python ints) then I want an __index__ check rather than an __int__ check. If I'm writing a function that allows general numeric inputs, then I'm not sure why I'd be calling 'int' on those inputs.

As another data point, complex supporting __int__ is a little bit of an oddity, since all that __int__ method does is raise a TypeError.

@Michael: are you in a position to share the use-case that motivated opening the issue? I'd be interested to see any concrete uses of typing.SupportsInt.

Maybe typing.SupportsIndex (or typing.UsableAsInt, or ... --- naming things is hard) is what we actually need?

On this particular issue: I'm not opposed to adding __int__ to fractions.Fraction purely for the sake of consistency, but it's not yet clear to me that it solves any real issue.
历史
日期 用户 动作 参数
2021-07-02 11:42:01mark.dickinson修改recipients: + mark.dickinson, mamrhein, josh.r
2021-07-02 11:42:01mark.dickinson修改messageid: <1625226121.04.0.567882853241.issue44547@roundup.psfhosted.org>
2021-07-02 11:42:01mark.dickinson链接issue44547 messages
2021-07-02 11:42:00mark.dickinson创建