[issue3081] Py_(X)SETREF macros

Changes by Raymond Hettinger : -- resolution: -> rejected status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing l

[issue3081] Py_(X)SETREF macros

Mark Dickinson added the comment: I agree with Raymond about the Py_INCREF. I could see more uses for this macro without the Py_INCREF, especially for things like in-place arithmetic operations. The following pattern appears a lot in code like Objects/longobject.c: Old code: /* add one to

[issue3081] Py_(X)SETREF macros

Antoine Pitrou added the comment: Py_ASSIGN could be a better name, but given the enthusiasm generated by this proposal, I think we might just as well close the issue. -- ___ Python tracker ___

[issue3081] Py_(X)SETREF macros

Jean-Paul Calderone added the comment: The name suggests a different behavior to me - I assumed it would set the reference count to a specific value. Maybe this is the kind of thing Raymond had in mind when he said "The mnemonic doesn't work for me". -- nosy: +exarkun __

[issue3081] Py_(X)SETREF macros

Changes by Jesús Cea Avión <[EMAIL PROTECTED]>: -- nosy: +jcea ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list mailing l

[issue3081] Py_(X)SETREF macros

Paul Pogonyshev <[EMAIL PROTECTED]> added the comment: Just to note, I proposed similar macro on the mailing list under the name Py_ASSIGN. -- nosy: +_doublep ___ Python tracker <[EMAIL PROTECTED]> __

[issue3081] Py_(X)SETREF macros

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Le samedi 28 juin 2008 à 20:12 +, Raymond Hettinger a écrit : > Raymond Hettinger <[EMAIL PROTECTED]> added the comment: > > -1 on the new macros. The mnemonic doesn't work for me and the example > code fragments are to my eyes less rea

[issue3081] Py_(X)SETREF macros

Raymond Hettinger <[EMAIL PROTECTED]> added the comment: -1 on the new macros. The mnemonic doesn't work for me and the example code fragments are to my eyes less readable than before. These add to the learning curve for reading and writing C extensions and provide nearly zero benefits. A

[issue3081] Py_(X)SETREF macros

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: This new patch avoids using temporary variables named "new", it also adopts the "do { ... } while (0)" idiom for definition of the macros. Added file: http://bugs.python.org/file10761/py_setref.patch ___ P

[issue3081] Py_(X)SETREF macros

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: A comment on the patch: Since object.h may be included from C++ extensions, you should not use a C++ keyword "new" as a variable name. -- nosy: +belopolsky ___ Python tracker <[EMAIL PROTEC

[issue3081] Py_(X)SETREF macros

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Sorry for the confusion. It seems to me this sort of thing would be useful in 2.6, too, so I marked it. -- versions: +Python 3.0 ___ Python tracker <[EMAIL PROTECTED]>

[issue3081] Py_(X)SETREF macros

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Benjamin, the patch is against py3k, also it might also apply cleanly on trunk... ___ Python tracker <[EMAIL PROTECTED]> ___ __

[issue3081] Py_(X)SETREF macros

Changes by Benjamin Peterson <[EMAIL PROTECTED]>: -- nosy: +benjamin.peterson type: -> feature request versions: +Python 2.6 -Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3081] Py_(X)SETREF macros

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: FWIW, I also wanted to propose for Py_INCREF(op) to evaluate as (op), so that it can be used as return or assignment value, e.g.: return Py_INCREF(result); or: self->var = Py_INCREF(obj); but it's perhaps a bit more controversial. __

[issue3081] Py_(X)SETREF macros

New submission from Antoine Pitrou <[EMAIL PROTECTED]>: This is an implementation of the Py_SETREF and Py_XSETREF macros proposed in http://mail.python.org/pipermail/python-dev/2008-May/079862.html As an example, I added a few conversions among the extension modules. -- components: Exte