On Fri, Nov 10, 2017 at 12:09:12PM +1000, Nick Coghlan wrote:
> I'm with Antoine on this - we should be pushing folks writing
> extension modules towards code generators like Cython, cffi, SWIG, and
> SIP, support libraries like Boost::Python, or safer languages like
> Rust (which can then be wrapp
On 9 November 2017 at 22:35, Antoine Pitrou wrote:
> On Thu, 9 Nov 2017 04:22:20 -0800
> Raymond Hettinger wrote:
>>
>> Probably, we're the wrong people to be talking about this. The proposal is
>> to make these macros part of the official API so that it starts to appear in
>> source code ever
09.11.17 14:22, Raymond Hettinger пише:
Stylistically, all of these seem awkward and I think there is more to it than
just the name. I'm not sure it is wise to pass complex inputs into a
two-argument macro that makes an assignment and has a conditional refcount
side-effect. Even now, one of t
Hum, to give more context to the discussion, the two discussed macros
are documented this way:
#ifndef Py_LIMITED_API
/* Safely decref `op` and set `op` to `op2`.
*
* As in case of Py_CLEAR "the obvious" code can be deadly:
*
* Py_DECREF(op);
* op = op2;
*
* The safe way is:
*
*
On Thu, 9 Nov 2017 04:22:20 -0800
Raymond Hettinger wrote:
>
> Probably, we're the wrong people to be talking about this. The proposal is
> to make these macros part of the official API so that it starts to appear in
> source code everywhere. The question isn't whether the above makes sense t
> On Nov 9, 2017, at 2:44 AM, Serhiy Storchaka wrote:
>
> If the problem is with naming, what names do you prefer? This already was
> bikeshedded (I insisted on discussing names before introducing the macros),
> but may now you have better ideas?
It didn't really seem like a bad idea until af
2017-11-09 3:08 GMT+01:00 Raymond Hettinger :
> I greatly prefer putting all the decrefs at the end to increase my confidence
> that it is okay to run other code that might reenter the current code.
There are 3 patterns to update C attributes of an object:
(1)
Py_XDECREF(obj->attr); // can call
Recently, Oren Milman fixed multiple bugs when an __init__() method
was called twice. IMHO Py_SETREF() was nicely used in __init__():
https://github.com/python/cpython/commit/e56ab746a965277ffcc4396d8a0902b6e072d049
https://github.com/python/cpython/commit/c0cabc23bbe474d542ff8a4f1243f4ec3cce5549
09.11.17 04:08, Raymond Hettinger пише:
On Nov 8, 2017, at 8:30 AM, Serhiy Storchaka wrote:
Macros Py_SETREF and Py_XSETREF were introduced in 3.6 and backported to all
maintained versions ([1] and [2]). Despite their names they are private. I
think that they are enough stable now and would
> On Nov 8, 2017, at 8:30 AM, Serhiy Storchaka wrote:
>
> Macros Py_SETREF and Py_XSETREF were introduced in 3.6 and backported to all
> maintained versions ([1] and [2]). Despite their names they are private. I
> think that they are enough stable now and would be helpful in third-party
> cod
08.11.17 18:37, Victor Stinner пише:
I like these macros!
Technically, would it be possible to use an inline function instead of
a macro for Python 3.7?
No, unless there is a way to pass arguments by reference in C99.
Py_SETREF(x, y) is the safe equivalent of
x = y;
Py_DECREF(x, y);
I like these macros!
Technically, would it be possible to use an inline function instead of
a macro for Python 3.7?
Victor
2017-11-08 17:30 GMT+01:00 Serhiy Storchaka :
> Macros Py_SETREF and Py_XSETREF were introduced in 3.6 and backported to all
> maintained versions ([1] and [2]). Despite the
Macros Py_SETREF and Py_XSETREF were introduced in 3.6 and backported to
all maintained versions ([1] and [2]). Despite their names they are
private. I think that they are enough stable now and would be helpful in
third-party code. Are there any objections against adding them to the
stable C AP
13 matches
Mail list logo
