On 10/9/2018 7:46 PM, Chris Jerdonek wrote:
On Tue, Oct 9, 2018 at 7:13 PM Benjamin Peterson <benja...@python.org> wrote:
On Tue, Oct 9, 2018, at 17:14, Barry Warsaw wrote:
On Oct 9, 2018, at 16:21, Steven D'Aprano <st...@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 :)
_______________________________________________
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
