On 10/9/2018 7:46 PM, Chris Jerdonek wrote: > On Tue, Oct 9, 2018 at 7:13 PM Benjamin Peterson <benjamin at python.org> wrote: >> On Tue, Oct 9, 2018, at 17:14, Barry Warsaw wrote: >>> On Oct 9, 2018, at 16:21, Steven D'Aprano <steve at pearwood.info> wrote: >>>> On Tue, Oct 09, 2018 at 10:26:50AM -0700, Guido van Rossum wrote: >>>>> My feeling is that limiting it to strings is fine, but checking those >>>>> strings for resembling identifiers is pointless and wasteful. >>>> Sure. The question is, do we have to support uses where people >>>> intentionally smuggle non-identifier strings as keys via **kwargs? >>> I would not be in favor of that. I think it doesn’t make sense to be >>> able to smuggle those in via **kwargs when it’s not supported by >>> Python’s grammar/syntax. >> Can anyone think of a situation where it would be advantageous for an implementation to reject non-identifier string kwargs? I can't. > One possibility is that it could foreclose certain security bugs from > happening. For example, if someone has an API that accepts **kwargs, > they might have the mistaken assumption that the keys are identifiers > without special characters like ";" etc, and so they could make the > mistake of thinking they don't need to escape / sanitize them. > > --Chris With that line of reasoning, one should make sure the data are identifiers too :) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20181009/7f067eea/attachment.html>
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