On Sun, 2006-03-26 at 21:50 +0200, "Martin v. Löwis" wrote:
> I don't know what specific application Barry has in mind, but I'm
> sure he can get it right (although it might be an interesting experiment
> to test that theory :-) In general, I would expect that people find
> it easier to get code i
On Sun, 2006-03-26 at 13:24 -0500, Raymond Hettinger wrote:
> We have a perfectly good way to iterate with PyIter_Next(). It may take a
> couple of extra lines, but it is easy to get correct and has no surprises.
> It
> seems that the only issue is that Barry says that he refuses to use the
On Sun, 2006-03-26 at 19:59 +0200, "Martin v. Löwis" wrote:
> If it is similar to PyDict_Next, it will have PyObject** /input/
> variables, which are really meant as PyObject* /output/ variables.
Yep, that's exactly what my posted patch does.
> For the caller, a clear usage strategy follows from
Raymond Hettinger wrote:
> Pardon, I bungled the terminology. PySet_Next returns a borrowed
> reference. That is problematic is arbitrary Python code can be run
> afterwards (such as PyObject_Hash in the example).
Not really. It is under the control of the caller of PySet_Next
what (if any) Pytho
>> The difference is that the PySet_Next returns pointers to the table keys and
>> that the mutation occurs AFTER the call to PySet_Next, leaving pointers to
>> invalid addresses. IOW, the function cannot detect the mutation.
>
> I'm coming late to the discussion: where did anybody ever suggest th
Raymond Hettinger wrote:
> The difference is that the PySet_Next returns pointers to the table keys and
> that the mutation occurs AFTER the call to PySet_Next, leaving pointers to
> invalid addresses. IOW, the function cannot detect the mutation.
I'm coming late to the discussion: where did an
