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

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

No longer reproduced.

--
resolution:  -> out of date
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Chris Angelico]

Change by Chris Angelico :


--
pull_requests: +13196

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[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".

ast.literal_eval() accepts unary minus for supporting negative numbers. In 
Python 2 "-42" was parsed as a single AST node Num(42), but in Python 3 it is 
parsed as UnaryOp(USub(), Num(42)). ast.literal_eval() accepts binary plus and 
minus for supporting complex numbers (there are oddities in this). The support 
of unary plus was added somewhere for unknown reason (see 884c71cd8dc6, no 
issue number), but it doesn't harm.

Below in the documentation: "It is not capable of evaluating arbitrarily 
complex expressions, for example involving operators or indexing." Arbitrarily 
complex expressions involving addition and subtraction (like "2017-10-10") was 
supported in Python 3 (but not in Python 2), but it was fixed in 3.7 (see 
issue31778). It doesn't support other operations or operations with non-numeric 
literals. It is oversight that UnaryOp(USub(), Constant(True)) is still 
accepted.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[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 ast.literal_eval doc says 
"The string or node provided may only consist of the following Python literal 
structures: strings, bytes, numbers, tuples, lists, dicts, sets, booleans, and 
None."

Since 'True', '(True,)', '[True]', '{True:True}', '+1', '-1' and '1+1j' are 
accepted as 'literal structures', it seems arbitrary that at least '+True' and 
'True+1j' are not.  ('+1', '1+1j' and especially '-1' seem to violate the 
limitations to 'literal', 'container', and 'no operator', but that is a 
different issue.)

I strongly agree that the acceptable string inputs and acceptable AST inputs 
should match.  The question is which version of the domain should be changed.  
I would at least mildly prefer that the issue be "ast.literal_eval should 
consistly treat False and True the same as 0 and 1.", which means expanding the 
string version.  As Raymond said, this is the general rule in Python.  What is 
the benefit of having a different rule for this one function?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Terry J. Reedy]

Change by Terry J. Reedy :


--
Removed message: https://bugs.python.org/msg312682

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[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 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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[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 error. But 
ast.literal_eval(ast.UnaryOp(ast.UAdd(), ast.Constant(True))) is successful by 
oversight.

And look at this from other side. What is the benefit of accepting "+True"? 
This doesn't make the code simpler.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[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 integers.

--
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
keywords: +patch
pull_requests: +5577
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
nosy: +benjamin.peterson

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[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 since bool is 
a subclass of int it passes this test.

The proposed PR makes ast.literal_eval() using tests for exact type. I don't 
think it is worth backporting since it affects only passing AST to 
ast.literal_eval(). Usually ast.literal_eval() is used for evaluating strings.

--
components: Library (Lib)
messages: 312485
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: ast.literal_eval() shouldn't accept booleans as numbers in AST
type: enhancement
versions: Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com