On 28.08.16 01:25, Terry Reedy wrote:
0. Do nothing.
The problem is not in pathological __index__. The problem is in executing Python code and releasing GIL. In multithread production code one thread can read a slice when other thread modifies a collection. In very very rare case it causes a crash (or worse, a corruption of data). We shouldn't left it as is.
1. Detect length change and raise.
It would be simpler solution. But I afraid that this can break third-party code that "just works" now. For example slicing a list "just works" if step is 1. It can return not what the author expected if a list grows, but it never crashes, and existing code can depends on current behavior. This solution is not applicable in maintained versions.
2. Retrieve length after any possible changes and proceed as normal.
This behavior looks the most expectable to me, but needs more work.
B. Add PySlice_GetIndicesEx2 (or ExEx?), which would receive *collection instead of length, so the length could be retrieved after the __index__ calls. Change calls. Deprecate PySlice_GetIndicesEx.
This is not always possible. The limit for a slice is not always the length of the collection (see multidimensional arrays). And how to determine the length? Call __len__? It can be overridden in Python, this causes releasing GIL, switching to other thread and modifying the collection. The original problem is returned.
And what versions should be patched?
Since this is heisenbug that can cause a crash, I think we should apply some solutions for all versions. But in develop version we a free to introduce small incompatibility.
I prefer 2A in maintained versions (may be including 3.3 and 3.4) and 2A or 1A in 3.6.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
