[issue35143] `from __future__ import annotations` has no effect inside `ast.parse`

[Eric V. Smith]

Eric V. Smith  added the comment:

I agree with Pablo's analysis. And this can't be backported, since it's a new 
feature. So I'm closing this issue.

--
resolution:  -> fixed
stage: needs patch -> 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

[issue35143] `from __future__ import annotations` has no effect inside `ast.parse`

[Kay Hayen]

Kay Hayen  added the comment:

Thanks a lot, Batuhan, this will feel a lot more correct, from my point of 
view, this could be closed unless there would be a backport.

--

___
Python tracker 

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

[issue35143] `from __future__ import annotations` has no effect inside `ast.parse`

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

I don't think this is a bug. Technically the 'from __future__ import 
annotations' is a compiler option, not an AST one. Also, the flag says that 
"annotations become strings at runtime" and at the point, we have an AST is not 
still runtime. The CO_FUTURE_ANNOTATIONS only takes place in the compiler that 
reverses the AST object into a string. If we make the AST aware of 
CO_FUTURE_ANNOTATIONS, then what the compiler will see in the presence of  
'from __future__ import annotations' would be different if you compile a module 
than if you parse it using ast.parse() and then compile the result (in the 
second case the compiler will see strings in the annotations, not AST nodes 
while in the first case it will see nodes). Additionally, doing this will limit 
tools that want to analyze the contents of those annotations before they get 
turned into strings (like type checker, linters...etc).

--
nosy: +pablogsal

___
Python tracker 

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

[issue35143] `from __future__ import annotations` has no effect inside `ast.parse`

[Batuhan]

Batuhan  added the comment:

> Having a real "ast.unparse" would be better however. It seems that the 
> building blocks are all there, just not in that form.

Now we have that :) 
https://docs.python.org/3.9/whatsnew/3.9.html#improved-modules

--

___
Python tracker 

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

[issue35143] `from __future__ import annotations` has no effect inside `ast.parse`

[Batuhan]

Batuhan  added the comment:

Hey @lukasz.langa, I want to work on this. Should we add an interface to 
_PyAST_ExprAsUnicode or just the bugfix for annotations?

--
nosy: +BTaskaya, benjamin.peterson

___
Python tracker 

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

[issue35143] `from __future__ import annotations` has no effect inside `ast.parse`

[Łukasz Langa]

Łukasz Langa  added the comment:

I think this is a bug, actually. It's going to be an incompatibility in 
`ast.parse` so we'll probably want to only enable it in Python 3.8.

This should have stringified annotations:

>>> p = ast.parse("""
... from __future__ import annotations
... a: 1
... """)
>>> p.body[1].annotation  # ACTUAL
<_ast.Num object at 0x1048cf470>

>>> p.body[1].annotation  # EXPECTED
<_ast.Str object at 0x1048cf6a0>

--
assignee:  -> lukasz.langa
stage:  -> needs patch
title: Annotations future requires unparse, but not accessible from Python -> 
`from __future__ import annotations` has no effect inside `ast.parse`
type: enhancement -> behavior

___
Python tracker 

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