Message286449
| Author | serhiy.storchaka |
|---|---|
| Recipients | christian.heimes, facundobatista, mark.dickinson, martin.panter, rhettinger, serhiy.storchaka, steven.daprano |
| Date | 2017-01-29.20:53:03 |
| SpamBayes Score | -1.0 |
| Marked as misclassified | Yes |
| Message-id | <1485723183.18.0.99950494371.issue18842@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
I concur with Raymond. This expands the API too much. Not just the float API, but the API of all numeric classes, including third-party classes. And since the existence of additional method in third-party classes (e.g. NumPy classes) can't be guarantied, this couldn't help in the case of msg286441. The less harmful way is making math.isfinite() and like supporting non-float numeric types. Always return False for integer types and fall back to the is_finite() method. But even this can be too expensive. |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2017-01-29 20:53:03 | serhiy.storchaka | set | recipients: + serhiy.storchaka, rhettinger, facundobatista, mark.dickinson, christian.heimes, steven.daprano, martin.panter |
| 2017-01-29 20:53:03 | serhiy.storchaka | set | messageid: <1485723183.18.0.99950494371.issue18842@psf.upfronthosting.co.za> |
| 2017-01-29 20:53:03 | serhiy.storchaka | link | issue18842 messages |
| 2017-01-29 20:53:03 | serhiy.storchaka | create | |