Terry J. Reedy <tjre...@udel.edu> added the comment: It is true that 'True' and 'False' are not literally literals. But as pre- and fixedly bound names, they function for Bool the same as 0 and 1 do for int.
Besides this, ast.literal_eval is not now limited to literal evaluation, but does compile-time computation of some constant expressions, in particular even nested tuples like '(1, (2, (3, (4,5))))' or '(False, (True, False))' and even some expressions yielding mutable objects, like '[1,2]' (see below). 'safe_eval' might be a better name now. The benefit of compressing 'True+True' to 2 at compile time is the same as compressing '1+1' to 2. Given what literal_eval actually is now, it is surprising and to me confusing that this is rejected, while a tuple with booleans is accepted (as it should be!). It is also a bug relative to the doc: "The string or node provided may only consist of the following Python literal structures: strings, bytes, numbers, tuples, lists, dicts, sets, *booleans*, and None." [*s added] So I think this issue should be flipped to "ast.literal_eval should consistently accept False and True" and marked as a bugfix. ---------- nosy: +terry.reedy _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32893> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
