Serhiy Storchaka added the comment:
According to the results of recent poll [1], Py_SETREF is the most popular
candidate. It was also one of leaders in previous poll [2], and this is a name
used in original Antoine's proposition [3].
[1]
Changes by Eldar Abusalimov eldar.abusali...@gmail.com:
--
nosy: +abusalimov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20440
___
___
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: -skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20440
___
___
Python-bugs-list
Jim Jewett added the comment:
I am changing this from High to Release blocker, because I think 3.3 should
make an explicit decision about whether to remove itself from the Affected
Versions list.
3.4 probably should too, since it is now in bug-fix mode.
Then this issue can go back to
STINNER Victor added the comment:
I am changing this from High to Release blocker, because I think 3.3
should make an explicit decision about whether to remove itself from the
Affected Versions list.
I don't understand. Which release does it block? There is no scheduled release
in short
Antoine Pitrou added the comment:
The patch adds new public APIs (C macros), I don't think it should be committed
to the maintenance branches.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20440
Larry Hastings added the comment:
Yeah, I'm not accepting this for 3.4 at this point, and I bet the other RMs
feel the same way.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20440
___
Georg Brandl added the comment:
Yes, this is new feature territory.
--
priority: release blocker - high
versions: +Python 3.5 -Python 2.7, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20440
Kristján Valur Jónsson added the comment:
Are you referring to the Py_LOCAL_INLINE macro?
I see that we have no Py_INLINE. Py_LOCAL_INLINE includes the static
qualifier, and in fact, if there is no USE_INLINE defined, then all that it
does is to add static.
Would having a Py_INLINE(type)
Kristján Valur Jónsson added the comment:
Well, Larry, I certainly am in no mood to start wrangling on python-dev. A 25
year old C standard is likely to be very mature and reliable by now. Why take
risks? :)
#Py_LOCAL_INLINE exists and demonstrates that we can make use of them when
Serhiy Storchaka added the comment:
Poll: http://comments.gmane.org/gmane.comp.python.devel/145974
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20440
___
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20440
___
Kristján Valur Jónsson added the comment:
Barring c++, are we using any C compilers that don't support inlines?
Imho these macros should be functions proper. Then we could do
Py_Assign(target, Py_IncRef(obj))
It's 2014 already.
--
___
Python
Stefan Krah added the comment:
Barring c++, are we using any C compilers that don't support inlines?
Not that I know of. libmpdec is C99, which seems to be supported by all
obscure commercial compilers on snakebite.
Also there have been no 3.x bug reports due to compilers choking on inline
Larry Hastings added the comment:
Barring c++, are we using any C compilers that don't support inlines?
CPython advertises itself as C89 compliant, and C89 doesn't have inlines. You
need to go to C99 to get inlines.
And before you ask--yes, we support a compiler that is not C99 compliant:
Tal Einat added the comment:
While we're bikeshedding, how about the more verbose PY_DECREF_AND_ASSIGN? That
makes it clearer that an INCREF is not done.
Regarding Kristján's suggestion of PY_ASSIGN and a complementary PY_STORE, IMO
these names are too similar and the difference between them
Serhiy Storchaka added the comment:
While we're bikeshedding, how about the more verbose PY_DECREF_AND_ASSIGN?
That makes it clearer that an INCREF is not done.
Py_ASSIGN_AND_DECREF would be more correct. And Py_CLEAR can be renamed to
Py_CLEAR_AND_XDECREF or Py_ASSIGN_NULL_AND_XDECREF.
Tal Einat added the comment:
PY_ASSIGN_AND_DECREF could seem to imply that the assigned value is DECREF-ed.
I think PY_DECREF_AND_ASSIGN makes it clearer that the original value is
DECREF-ed.
I like PY_ASSIGN_NULL_AND_DECREF, though for the same reason as above, I'd name
it
Kristján Valur Jónsson added the comment:
Better yet, embrace c++ and smart pointers :;-)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20440
___
Kristján Valur Jónsson added the comment:
These macros work as assignment with builtin decref,
i.e. a smart replacement for =
We could resolve this by calling them Py_ASSIGN Py_XASSIGN
and having complementary macros Py_STORE/Py_XSTORE that will incref the new
value.
However, with an added
Serhiy Storchaka added the comment:
Py_ASSIGN was proposed by Paul Pogonyshev in msg70798, and this also looks good
to me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20440
___
Serhiy Storchaka added the comment:
I think Raymond's original concern still applies: The macros do add to the
learning curve.
I agree. But alternative solution is Victor's original patch which replaces
potential bugs by inlined body of Py_REPLACE/Py_XREPLACE. This is explicit, but
more
Martin v. Löwis added the comment:
I think Raymond's original concern still applies: The macros do add to the
learning curve. I would personally expect that Py_REPLACE(op, op2) does an
INCREF on op2, but it does not.
Explicit is better than implicit.
--
nosy: +loewis
Serhiy Storchaka added the comment:
Unless some known bugs are being fixed, this should be 3.4 only.
For example here is a bug very similar to a bug fixed in issue16447.
class Nasty(str):
def __del__(self):
C.__qualname__ = other
class C:
pass
C.__qualname__ = Nasty(abc)
Changes by Serhiy Storchaka storch...@gmail.com:
--
priority: normal - high
type: behavior - crash
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20440
___
New submission from Serhiy Storchaka:
Proposed patches replaced idiomatic code
Py_DECREF(ptr);
ptr = new_value;
to Py_REPLACE(ptr, new_value); which is expanded to
{
PyObject *__tmp__ = ptr;
ptr = new_value;
Py_DECREF(__tmp__);
}
(and same for
Changes by Serhiy Storchaka storch...@gmail.com:
Added file: http://bugs.python.org/file33803/py_replace-2.7.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20440
___
Changes by Serhiy Storchaka storch...@gmail.com:
Added file: http://bugs.python.org/file33802/py_replace-3.3.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20440
___
Changes by Serhiy Storchaka storch...@gmail.com:
--
keywords: +patch
Added file: http://bugs.python.org/file33801/py_replace-3.4.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20440
___
Antoine Pitrou added the comment:
Something similar was proposed in issue3081.
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20440
___
Serhiy Storchaka added the comment:
I do not understand why that issue was closed. Probably Py_SETREF is not the
best name but this can be discussed. Adverse idea about Py_INCREF also looked
questionable. But many people supported the introduction of a macro for safe
replacement.
And now we
Brett Cannon added the comment:
It all seems like a good idea to me and I like the Py_REPLACE naming (I was
going to suggest Py_SWAP, but Py_XSWAP looks too weird to me).
--
nosy: +brett.cannon
___
Python tracker rep...@bugs.python.org
Raymond Hettinger added the comment:
Unless some known bugs are being fixed, this should be 3.4 only.
--
nosy: +rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20440
___
33 matches
Mail list logo
