The following behavior was witnessed in v3.6 & v3.8.

When deriving from a Generic base class, there's an inconsistency in the order of operation within the `__new__()` function between the case of deriving WITH generic-argument specification and WITHOUT.

It might be best explained in the following example:

```
import typing

T = typing.TypeVar('T')
class Base(typing.Generic[T]):
    some_attribute: typing.Any

    def __init_subclass__(cls, **kwargs):
        assert hasattr(cls, 'some_attribute')

class Class1(Base):       # OK
    some_attribute = 123  

class Class2(Base[int]):  # AssertionError
    some_attribute = 123  
```

In this examples, the base class implements `__init_subclass__` to ensure that sublclasses define an attribute. In the case of `Class1`, the class derives without specifying the type-arguments for the class. In that case, the `__init_subclass__` is called after the `some_attribute` is defined. In the second case, however, because I pass the `int` type-argument to the base-class, for some reason `__init_subclass__` is called BEFORE the class' definition.

Hi Erez, thank you for the bug report. What minor version of 3.8 are you using exactly? I'm able to reproduce this on 3.6.8, but not on 3.8.5.

BTW, Python 3.8 is no longer receiving bugfixes - only security fixes. The only versions still getting bugfixes right now are 3.9.0, 3.10b1, 3.11a1. I'm unable to reproduce this on those 3 versions. So I'm inclined to close this issue as there's not much we can do about it (we can't backport a fix to 3.8). Sorry :(.

You're right. I accidentally used 3.6.9 both times. Thank you anyway. 

Regardless, that's unfortunate that you don't support the version 3.8 anymore, since many frameworks do not officially support 3.9 as of yet (pytorch, for example).

Also Tensorflow.

Since this only affects 3.6 which is no longer receiving bugfixes, I'm closing this issue.

3.7 and higher do not have this bug. So one way forward is to upgrade to 3.7 or 3.8 - both of which are supported by most major libraries.

If this bug reappears again in 3.10, please do not hesitate to re-open this issue. Thanks!