[issue39463] ast.Constant, bytes, and ast.unparse

2020-11-16 Thread Batuhan Taskaya
Batuhan Taskaya added the comment: We added the warnings, and I believe we can close this safely (since there is no intend to change the behavior of ast.unparse) -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python

[issue39463] ast.Constant, bytes, and ast.unparse

2020-01-27 Thread Pablo Galindo Salgado
Pablo Galindo Salgado added the comment: > Maybe we should only offically allow things that can be generated by > ast.parse? Yes, I think this is the way to go. In the future, we can expand the function to support more things, but for the first release, it should be as much restrictive as

[issue39463] ast.Constant, bytes, and ast.unparse

2020-01-27 Thread Batuhan
Batuhan added the comment: > Maybe we need to clarify to the docs of 'unparse' that the AST object needs > to be valid. As I stated earlier, constant tuple like things are valid but don't fit on description. Maybe we should only offically allow things that can be generated by ast.parse? We

[issue39463] ast.Constant, bytes, and ast.unparse

2020-01-27 Thread Pablo Galindo Salgado
Pablo Galindo Salgado added the comment: Maybe we need to clarify to the docs of 'unparse' that the AST object needs to be valid. -- ___ Python tracker ___

[issue39463] ast.Constant, bytes, and ast.unparse

2020-01-27 Thread Pablo Galindo Salgado
Change by Pablo Galindo Salgado : -- Removed message: https://bugs.python.org/msg360757 ___ Python tracker ___ ___ Python-bugs-list

[issue39463] ast.Constant, bytes, and ast.unparse

2020-01-27 Thread Pablo Galindo Salgado
Pablo Galindo Salgado added the comment: > First, it breaks backward compatibility for older code that creates ast.Num > without specifying kind The ast changes during versions, and in the current master there are no "Num" nodes, so not much we could do there sadly. >Second, since bytes

[issue39463] ast.Constant, bytes, and ast.unparse

2020-01-27 Thread Pablo Galindo Salgado
Pablo Galindo Salgado added the comment: > First, it breaks backward compatibility for older code that creates ast.Num > without specifying kind The ast changes during versions, and in the current master there are no "Num" nodes, so not much we could do there safely. >Second, since bytes

[issue39463] ast.Constant, bytes, and ast.unparse

2020-01-27 Thread Batuhan
Batuhan added the comment: Origin of this thread: https://github.com/simonpercivall/astunparse/pull/44 -- nosy: +BTaskaya, pablogsal ___ Python tracker ___

[issue39463] ast.Constant, bytes, and ast.unparse

2020-01-27 Thread Tal Ben-Nun
Change by Tal Ben-Nun : -- versions: +Python 3.8 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39463] ast.Constant, bytes, and ast.unparse

2020-01-27 Thread Tal Ben-Nun
New submission from Tal Ben-Nun : In Python 3.8, the "kind" field was introduced into the Constant AST class. This brings about a problem when unparsing the AST for various packages. First, it breaks backward compatibility for older code that creates ast.Num without specifying kind (which is