This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author mark.dickinson
Recipients BTaskaya, Mark.Shannon, christian.heimes, josh.r, mark.dickinson, pablogsal, rhettinger, serhiy.storchaka
Date 2020-11-25.12:02:55
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1606305775.5.0.721758716668.issue42454@roundup.psfhosted.org>
In-reply-to
Content
> At least for optimization, IMHO it worth taking the shot.

For me, this feels a bit backwards: IMO you should decide what behaviour you want first, implement the desired behaviour, and then optimize (if possible) while keeping that same desired behaviour. It's rare that we want an optimization to drive behaviour changes.

So for me, the key question that needs answering is: independent of any performance changes, do we want the behaviour change? Specifically, do we want something like "d = {}; d[1:2] = True" to "work" in Python 3.10, given that in previous releases it raises TypeError? What are the potential benefits or drawbacks for the user?

If you can get consensus that the behaviour change is fine, then by all means go ahead with the optimization. But I think the behaviour question needs to be answered first.
History
Date User Action Args
2020-11-25 12:02:55mark.dickinsonsetrecipients: + mark.dickinson, rhettinger, christian.heimes, Mark.Shannon, serhiy.storchaka, josh.r, pablogsal, BTaskaya
2020-11-25 12:02:55mark.dickinsonsetmessageid: <1606305775.5.0.721758716668.issue42454@roundup.psfhosted.org>
2020-11-25 12:02:55mark.dickinsonlinkissue42454 messages
2020-11-25 12:02:55mark.dickinsoncreate