I have discovered that InitVar's are passed in a surprising way to the __post_init__ method of python dataclasses.  The following program illustrates the problem:

=====

from dataclasses import InitVar, dataclass

@dataclass
class Foo:
    bar: InitVar[str]
    quux: InitVar[str]

    def __post_init__(self, quux: str, bar: str) -> None:
        print(f"bar is {bar}; quux is {quux}")

Foo(bar="a", quux="b")

=====

The output (on python 3.7.3 and 3.8.0a3) is (incorrectly):

bar is b; quux is a

This behavior seems like a bug to me, do you agree?

I have not looked into the reason why it behaves this way, but I suspect that the InitVar args are passed positionally, rather than as key words, to __post_init__.  This requires the order of arguments in the definition of __post_init__ to be identical to the order in which they are specified in the class.  I would expect the arguments to be passed as keywords instead, which would remove the ordering dependency.  If there is agreement that the current behavior is undesirable, I can look into creating a patch to change it.

I think using named parameters in the call to __post_init__ is reasonable. It's currently positional.

Should we also be checking for __post_init__ to have positional only arguments / syntax in the signature. I tried a simple fix of f.name + "=" + f.name to pass them as keyword always where current tests and reported example passes but with positional arguments it could be a problem.

https://github.com/python/cpython/blob/5c0c325453a175350e3c18ebb10cc10c37f9595c/Lib/dataclasses.py#L516

I don't think that's necessary. We should just document that parameters are passed by name to __post_init__. This would have to be a 3.9 feature, since it's not strictly backward compatible.