On Tue, Aug 30, 2016 at 2:31 PM, Dima Tisnek <dim...@gmail.com> wrote: > On 30 August 2016 at 14:13, Serhiy Storchaka <storch...@gmail.com> wrote: >>> 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. > > Serhiy, > > If dictionary is iterated in thread1 while thread2 changes the > dictionary, thread1 currently raises RuntimeError. > > Would cloning current dict behaviour to slice with overridden > __index__ make sense? > > > I'd argue 3rd party code depends on slicing not to raise an exception, > is same as 3rd party code depending on dict iteration not to raise and > exception; If same container may be concurrently used in another > thread, then 3rd party code is actually buggy. It's OK to break such > code. > > > Just my 2c. > _______________________________________________ > 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/fijall%40gmail.com
I'm with Dima here. It's more complicated - if the third party rely on the code working when one thread slices while the other thread modifies that gives implicit atomicity requirements. Those specific requirements are very hard to maintain across the python versions and python implementations. Replicating the exact CPython behavior (for each CPython version too!) is a major nightmare for such specific scenarios. I propose the following: * we raise an error if detected -or- * we define the exact behavior what it means to modify the collection in one thread while the other is slicing it (what do you get? what are the guarantees? does it also apply if the list is resized?) _______________________________________________ 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
