While I was working on making 'future annotations' default, I noticed that dataclasses acts differently under the annotation feature. One example would be the file [signature.py]:

[ without future import]
 $ python t.py
X(a: int, b: int)
[ with future import]
 $ python t.py
X(a: '_type_a', b: '_type_b') -> '_return_type'

This is causing too much test to fail,
AssertionError: '_return_type' is not None

- C(x:'_type_x')->'_return_type'
+ C(x:collections.deque)

- C(x:'_type_x'=<factory>)->'_return_type'
+ C(x:collections.deque=<factory>)

- C(x:'_type_x')->'_return_type'
+ C(x:List[int])

(and more)

It,sounds like you are trying to get the effect of putting 'from __future__ import dataclasses' at the top of dataclasses'.py, right? Are you saying that without this, the output of the test script is correct?

> It,sounds like you are trying to get the effect of putting 'from __future__ import dataclasses' at the top of dataclasses'.py, right?

Yes, since compile will automatically inherit the flags of the current frame to the compiled code I'm basically inserting a 'future annotations' import at the top of the file. 

> Are you saying that without this, the output of the test script is correct?

Yes.

Have you come up with a fix yet? (Preferably a fix that can be applied locally to dataclasses.py.)

> Have you come up with a fix yet? (Preferably a fix that can be applied locally to dataclasses.py.)

I'm working on it, but no luck so far.

Hmm. That's a regression, at least from 3.7, which is the only version I have ready access to:

$ python3
Python 3.7.3 (default, Mar 27 2019, 13:36:35) 
[GCC 9.0.1 20190227 (Red Hat 9.0.1-0.8)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import dataclasses
>>> @dataclasses.dataclass
... class X:
...   a: int
...   b:int
... 
>>> X.__doc__
'X(a: int, b: int)'
>>> 

$ python3
Python 3.7.3 (default, Mar 27 2019, 13:36:35) 
[GCC 9.0.1 20190227 (Red Hat 9.0.1-0.8)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from __future__ import annotations
>>> import dataclasses
>>> @dataclasses.dataclass
... class X:
...   a: int
...   b:int
... 
>>> X.__doc__
"X(a: 'int', b: 'int')"

> Hmm. That's a regression, at least from 3.7, which is the only version I have ready access to:

That is the same behavior with the current master, the problem I am having is related to using annotations feature on dataclasses itself rather than the program that imports it. I've tested script.py on 3.7.5 and it gives the same output.

To clarify, for Eric: what Batuhan did is effectively adding `from __future__ import annotations` to the top of dataclasses.py.

I believe the root cause is that dataclasses creates functions by synthesizing `def` statements (in _create_fn()) and the annotations there are references to variables in a dedicated namespace. Maybe we should patch the __annotations__ attribute of the result before sticking it into the class?

I see. Not sure how I overlooked that. Thanks.

At first blush, I think your approach would work.

I have applied Guido's suggestion and it looks like it is working.

(I applied it to my own branch, don't know if a seperate PR needed)

You can do this as part of your mega-PR to turn on `from __future__ import annotations` by default.