> Sorry, you're wrong. First, it's asterisk asterisk locals(), I meant what I wrote. Someone, in a rush to criticize about a topic on which they are ignorant,

> Sorry, you're wrong. First, it's asterisk asterisk locals(), I meant what I wrote. Someone, in a rush to criticize about a topic on which they are ignorant, didn't consult the Python documentation: https://docs.python.org/3/library/stdtypes.html#str.format_map https://docs.python.org/3/library/stdtypes.html#str.format_m... > they don't show here for some reason. Asterisks only show in code blocks. They denote italics in HN's markup. Double asterisks outside of a code block begin and end empty italicized text. ** no italics because we're in a code block > Second, the parser at compile time pulls out the actual expressions and fills them in to a .format call. It __does not__ use locals! I'll quote myself here, since you missed the first part of this sentence when jumping to a conclusion about why security is irrelevant, but we need to blacklist a well-understood and widely used builtin function anyway. >> Technically, PEP-0498 states that we're not exposing a full locals() or globals(), but this actually matters very little. But, while we're trying to be pedantic, let's actually be pedantic: >>> import dis >>> dis.dis('f"{foo}"') 1 0 LOAD_NAME 0 (foo) 2 FORMAT_VALUE 0 4 RETURN_VALUE Shouldn't I be seeing some LOAD_CONST, LOAD_ATTR, and CALL_FUNCTION somewhere? >>> import dis >>> dis.dis('"{foo}".format("bar")') 1 0 LOAD_CONST 0 ('{foo}') 2 LOAD_ATTR 0 (format) 4 LOAD_CONST 1 ('bar') 6 CALL_FUNCTION 1 8 RETURN_VALUE If you'd like, you can go ahead and examine what it is that FORMAT_VALUE does (hint: invokes PyObject_Format which is defined in abstract.c around line 670 in the Python-3.6.0 tarball).