Motivating example:

>>> @dataclass
... class A:
...   x: InitVar[int] = 0
...   y: int = 1
... 
>>> a = A()
>>> a.x
0
>>> a.y
1

PEP-557 does not specify if fields annotated with InitVar[...] are available on the resulting dataclass. However, they are not part of the dataclass structure and are only used for __*init__ generation, so perhaps they shouldn't be? Wdyt?

This is just how Python works. The default values for .x and .y are set on the class A, not its instances. Here's the equivalent without dataclasses:

>>> class A:
...   x = 0
...   y = 1
...
>>> a = A()
>>> a.x
0
>>> a.y
1
>>> a.__dict__
{}
>>> A.__dict__
mappingproxy({'__module__': '__main__', 'x': 0, 'y': 1, '__dict__': <attribute '__dict__' of 'A' objects>, '__weakref__': <attribute '__weakref__' of 'A' objects>, '__doc__': None})

Note that the instance "a" has nothing in its __dict__, but the values A.x and A.y are none the less available through the instance "a".

The only way to avoid this would be for @dataclass to delete the values from A, but that's not a change I'd be willing to make.

Is this causing some actual problem in any code?

I understand that this is a side-effect of having a default value, but I was hoping we could delattr InitVar's in @dataclass. 

I'm not aware of this causing problems, but it does feel a bit unsatisfying that InitVar's with defaults are kept in the class namespace. 

Do you see what could go wrong if we delete them?

I'm not aware of what problems it would cause, but there's no doubt someone who's relying on it.

Since it's a behavior of normal classes, changing it would violate dataclasses desire (not always realized) to have as little impact as possible on the class that it's decorating.

You could add another decorator to do this, or handle it in a __post_init__ function if needed.

I don’t see any way of changing this behavior, so I’m going to close this issue.