You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In particular, I've found PySet_Next() to be disasterously
error-prone (and have had to fix several hard-to-find bugs
directly attributable this function). There was some need
for it in the PyDict API because it fetched key and value
pointers at the same time and allowed direct modification
of values. This of course does not apply to sets which do
not have a value field.
The PySet_Clear() function should be PyObject_Clear() like
other functions that have tp_slots. There is no more of a
case for this function than there would be for PySet_Repr,
PySet_Len, PySet_IsTrue, or PySet_Print.
The PySet_Update() function gets in the way of my future
development plans for this module.
None of these functions are necessary. They simply
reflect Barry's programming style and views on having fat,
overly-concrete APIs.
This patch is against my wishes for the module. As the
module author and principal maintainer, if I still have a
say in the module's development, I strongly prefer
rejection of this patch.
FWIW, I'm open to PyObject_Clear() for an abstract access
to the tp_clear slot.
Also, for Barry's use only, I'm open to a semi-private
_PySet_Next() that isn't part of the official API but
gives a Barry-specific hook. It should not be a public
function because of all the problems with the approach.
Likewise, _PySet_Update() could be done just for Barry's
group. I need to keep PySet_Update() open until Py2.6
since the API may evolve to allow a variable length
argument list.
Activity
warsaw commentedon Mar 25, 2006
This patch adds PySet_Next(), PySet_Update(), and
PySet_Clear(), three very useful API calls when you're
dealing with concrete PySet objects.
Patch includes tests and documentation.
rhettinger commentedon Mar 25, 2006
Logged In: YES
user_id=80475
Guido, please reject this patch.
I laid-out my reasoning in these two posts:
http://mail.python.org/pipermail/python-dev/2006-March/062652.html
http://mail.python.org/pipermail/python-dev/2006-March/062737.html
In particular, I've found PySet_Next() to be disasterously
error-prone (and have had to fix several hard-to-find bugs
directly attributable this function). There was some need
for it in the PyDict API because it fetched key and value
pointers at the same time and allowed direct modification
of values. This of course does not apply to sets which do
not have a value field.
The PySet_Clear() function should be PyObject_Clear() like
other functions that have tp_slots. There is no more of a
case for this function than there would be for PySet_Repr,
PySet_Len, PySet_IsTrue, or PySet_Print.
The PySet_Update() function gets in the way of my future
development plans for this module.
None of these functions are necessary. They simply
reflect Barry's programming style and views on having fat,
overly-concrete APIs.
This patch is against my wishes for the module. As the
module author and principal maintainer, if I still have a
say in the module's development, I strongly prefer
rejection of this patch.
rhettinger commentedon Mar 26, 2006
Logged In: YES
user_id=80475
FWIW, I'm open to PyObject_Clear() for an abstract access
to the tp_clear slot.
Also, for Barry's use only, I'm open to a semi-private
_PySet_Next() that isn't part of the official API but
gives a Barry-specific hook. It should not be a public
function because of all the problems with the approach.
Likewise, _PySet_Update() could be done just for Barry's
group. I need to keep PySet_Update() open until Py2.6
since the API may evolve to allow a variable length
argument list.
gvanrossum commentedon Mar 27, 2006
Logged In: YES
user_id=6380
I'm rejecting this unread, because I'm not ready to jump
into this issue. The discussion should continue without me.
warsaw commentedon Mar 30, 2006
Logged In: YES
user_id=12800
r43465