A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2016-August/145963.html below:

[Python-Dev] What do we do about bad slicing and possible crashes (issue 27867)

[Python-Dev] What do we do about bad slicing and possible crashes (issue 27867) [Python-Dev] What do we do about bad slicing and possible crashes (issue 27867)Dima Tisnek dimaqq at gmail.com
Tue Aug 30 08:31:41 EDT 2016
On 30 August 2016 at 14:13, Serhiy Storchaka <storchaka at 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.
More information about the Python-Dev mailing list

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