Message312682
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. |
|
Date |
User |
Action |
Args |
2018-02-24 01:17:14 | terry.reedy | unlink | issue32893 messages |
2018-02-24 01:10:24 | terry.reedy | set | recipients:
+ terry.reedy, rhettinger, benjamin.peterson, serhiy.storchaka |
2018-02-24 01:10:24 | terry.reedy | set | messageid: <1519434624.41.0.467229070634.issue32893@psf.upfronthosting.co.za> |
2018-02-24 01:10:24 | terry.reedy | link | issue32893 messages |
2018-02-24 01:10:22 | terry.reedy | create | |
|