To avoid the exception in the discard method, it could be implemented as:
def discard(self, element):
"""Remove an element from a set if it is a member.
If the element is not a member, do nothing.
"""
try:
self._data.pop(element, None)
excep
> To avoid the exception in the discard method, it could be
> implemented as:
>
> def discard(self, element):
> """Remove an element from a set if it is a member.
>
> If the element is not a member, do nothing.
> """
> try:
> self._data.pop(element
>> But the dict.pop method is about 12 times faster. Is this worth doing?
>
>The 2.4 builtin set's discard function looks like it does roughly the same
>as the 2.3 sets.Set. Have you tried comparing a C version of your version
>with the 2.4 set to see if there are speedups there, too?
Ah. I had f
>>> But the dict.pop method is about 12 times faster. Is this
>>> worth doing?
>>
>> The 2.4 builtin set's discard function looks like it does
>> roughly the same as the 2.3 sets.Set. Have you tried comparing
>> a C version of your version with the 2.4 set to see if there are
>> speedups there,
>The C implementation has this code:
>
>"""
> if (PyDict_DelItem(so->data, item) == -1) {
> if (!PyErr_ExceptionMatches(PyExc_KeyError))
> return NULL;
> PyErr_Clear();
> }
>"""
>
>Which is more-or-less the same as the sets.Set version,
On Fri, 2005-03-18 at 01:19, Andrew McNamara wrote:
> No, exceptions are fast at the C level - all they do is set a flag. The
> expense of exceptions is saving a restoring python frames, I think,
> which doesn't happen in this case. So the current implementation is
> ideal for C code - clear and f
