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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4