[issue32893] ast.literal_eval() shouldn't accept booleans as numbers in AST

2020-05-16 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: No longer reproduced. -- resolution: -> out of date stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue32893] ast.literal_eval() shouldn't accept booleans as numbers in AST

2019-05-13 Thread Chris Angelico
Change by Chris Angelico : -- pull_requests: +13196 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue32893] ast.literal_eval() shouldn't accept booleans as numbers in AST

2018-02-23 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: The definition of "Python literal structures" is not specified, but it is implied that ast.literal_eval() should accept signed numbers and tuple/list/set/dict displays consisting of "Python literal structures".

[issue32893] ast.literal_eval() shouldn't accept booleans as numbers in AST

2018-02-23 Thread Terry J. Reedy
Terry J. Reedy added the comment: Whoops, my previous response was wrong as written because I wrongly thought that if literal_eval accepts number_literal + imaginary_literal, it would also accept number_literal + number_literal. I am replacing it with the following. The

[issue32893] ast.literal_eval() shouldn't accept booleans as numbers in AST

2018-02-23 Thread Terry J. Reedy
Change by Terry J. Reedy : -- Removed message: https://bugs.python.org/msg312682 ___ Python tracker ___

[issue32893] ast.literal_eval() shouldn't accept booleans as numbers in AST

2018-02-23 Thread Terry J. Reedy
Terry J. Reedy 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

[issue32893] ast.literal_eval() shouldn't accept booleans as numbers in AST

2018-02-21 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: This doesn't look like Python literal. And if the function accepts a one particular non-literal the user can except that it accepts other looking similarly non-literal, that is false. Actually ast.literal_eval("+True") is

[issue32893] ast.literal_eval() shouldn't accept booleans as numbers in AST

2018-02-21 Thread Raymond Hettinger
Raymond Hettinger added the comment: What harm comes from accepting expressions like "+True" or "True+2j"? While weird looking, those are valid Python expressions, so this doesn't seem like a bug. A key feature of booleans is that they are interoperable with

[issue32893] ast.literal_eval() shouldn't accept booleans as numbers in AST

2018-02-21 Thread Serhiy Storchaka
Change by Serhiy Storchaka : -- keywords: +patch pull_requests: +5577 stage: -> patch review ___ Python tracker ___

[issue32893] ast.literal_eval() shouldn't accept booleans as numbers in AST

2018-02-21 Thread Serhiy Storchaka
Change by Serhiy Storchaka : -- nosy: +benjamin.peterson ___ Python tracker ___

[issue32893] ast.literal_eval() shouldn't accept booleans as numbers in AST

2018-02-21 Thread Serhiy Storchaka
New submission from Serhiy Storchaka : Currently ast.literal_eval() accepts AST representing expressions like "+True" or "True+2j" if constants are represented as Constant. This is because the type of the value is tested with `isinstance(left, (int, float))` and