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>
Python-bugs-list mailing list

Reply via email to