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
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com