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.
Python tracker <rep...@bugs.python.org>
Python-bugs-list mailing list