On Tue, Oct 9, 2018 at 7:49 PM Chris Jerdonek <chris.jerdonek@gmail.com> wrote:
On Tue, Oct 9, 2018, at 17:14, Barry Warsaw wrote:
On Oct 9, 2018, at 16:21, Steven D'Aprano <steve@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
On Tue, Oct 9, 2018 at 7:13 PM Benjamin Peterson <benjamin@python.org> wrote: 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.
Hm, that's not an entirely unreasonable concern. How would an attacker get such keys *into* the dict? One possible scenario would be something that parses a traditional web query string into a dict, passes it down through **kwds, and then turns it back into another query string without proper quoting. But the most common (and easiest) way to turn a dict into a query string is calling urlencode(), which quotes unsafe characters. I think we needn't rush this (and when in doubt, status quo wins, esp. when there's no BDFL :-). -- --Guido van Rossum (python.org/~guido)