Message238658
| Author | petr.viktorin |
|---|---|
| Recipients | ethan.furman, petr.viktorin, serhiy.storchaka, skrah |
| Date | 2015-03-20.12:43:30 |
| SpamBayes Score | -1.0 |
| Marked as misclassified | Yes |
| Message-id | <1426855410.95.0.297635930032.issue23699@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
Serhiy: Thanks for looking at this! I think it should fall in the same category as Py_RETURN_TRUE or Py_RETURN_NONE. Sure, it's easy to reimplement, but a lot of extensions need it; why should everyone need to write the same code in a dozen different ways? I specifically want this usable in third-party code. The implementation of Py_RICHCOMPARE is in the first patch. The second is example use. The signature mirrors richcmpfunc. Why would op be better as first argument? Stefan: Which optimizer should I look at? Is it important to generate the same code? Sorry if I'm asking for something obvious, I'm not a regular here. |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2015-03-20 12:43:31 | petr.viktorin | set | recipients: + petr.viktorin, skrah, ethan.furman, serhiy.storchaka |
| 2015-03-20 12:43:30 | petr.viktorin | set | messageid: <1426855410.95.0.297635930032.issue23699@psf.upfronthosting.co.za> |
| 2015-03-20 12:43:30 | petr.viktorin | link | issue23699 messages |
| 2015-03-20 12:43:30 | petr.viktorin | create | |