Message259784
| Author |
serhiy.storchaka |
| Recipients |
rhettinger, serhiy.storchaka |
| Date |
2016年02月07日.11:35:47 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1454844948.19.0.535754766244.issue26200@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
On 28.02.14 15:58, Kristján Valur Jónsson wrote:
> Also, for the equivalence to hold there is no separate Py_XSETREF, the X
> behaviour is implied, which I favour. Enough of this X-proliferation
> already!
On 16.12.15 16:53, Random832 wrote:
> I think "SET" names imply that it's safe if the original
> reference is NULL. This isn't an objection to the names, but if
> it is given one of those names I think it should use Py_XDECREF.
It was my initial intension. But then I had got a number of voices for single macros.
On 16.12.15 23:16, Victor Stinner wrote:
> I would prefer a single macro to avoid bugs, I don't think that such
> macro has a critical impact on performances. It's more designed for
> safety, no?
On 17.12.15 08:22, Nick Coghlan wrote:
>> 1. Py_SETREF
>
> +1 if it always uses Py_XDECREF on the previous value (as I'd expect
> this to work even if the previous value was NULL)
Some objections were repeated by their authors few times. And I had no one voice for separate macros (except my).
In the light of your objection we should reraise this issue on Python-Dev.
Now, after applying patches, it would be harder to split Py_SETREF on two macros. But I tried to not replace a Py_DECREF with a Py_SETREF in performance critical code (e.g. in PyDict_SetItem). |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2016年02月07日 11:35:48 | serhiy.storchaka | set | recipients:
+ serhiy.storchaka, rhettinger |
| 2016年02月07日 11:35:48 | serhiy.storchaka | set | messageid: <1454844948.19.0.535754766244.issue26200@psf.upfronthosting.co.za> |
| 2016年02月07日 11:35:48 | serhiy.storchaka | link | issue26200 messages |
| 2016年02月07日 11:35:47 | serhiy.storchaka | create |
|