[python-experimental] Allow models to have properties of type self

[spacether]

This updates the python-experimental generator to allow a model to have properties of type self.
An example model is a Player which stores an enemyPlayer also of type player.

See this use case example:

  Player:
    type: object
    required:
      - name
    properties:
      name:
        type: string
      enemyPlayer:
        type: object
        $ref: '#/components/schemas/Player'

And our python code demonstrating that it works:

        jim = petstore_api.Player(
            name="Jim",
            enemy_player=petstore_api.Player(name="Sam")
        )

This was fixed by converting class.openapi_types into a class method, which prevents the openapi_types code from being run at import time.
We also removed the module name from the dataType of the property if the property in self's model.

Test Verification

A test has been added demonstrating that this works at https://github.com/spacether/openapi-generator/blob/issue_4885_allow_self_properties/samples/client/petstore/python-experimental/test/test_player.py#L32

If merged, this will resolve:
#4885

• Read the contribution guidelines.
• If contributing template-only or documentation-only changes which will change sample output, build the project before.
• Run the shell script(s) under ./bin/ (or Windows batch scripts under.\bin\windows) to update Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit, and these must match the expectations made by your contribution. You only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the code or mustache templates for a language ({LANG}) (e.g. php, ruby, python, etc).
• File the PR against the correct branch: master, 4.3.x, 5.0.x. Default: master.
• Copy the technical committee to review the pull request if your PR is targeting a particular programming language.

Python technical-committee:
@taxpon (2017/07) @frol (2017/07) @mbohlool (2017/07) @cbornet (2017/09) @kenjones-cisco (2017/11) @tomplus (2018/10) @Jyhess (2019/01) @slash-arun (2019/11) @spacether (2019/11)

@ethan92429

[eak24]

@spacether I just ran into another issue using this PR. It is in the resolution of the discriminator. If a model specifies that it is a grandchild of the base model, the discriminator for that grandkid won't be found because the client only looks in the discriminators of the base. The way around this would be to specify every subtype possible, which would be extraordinarily ugly for a large tree that inherits all from one main type (a common pattern for my company). Instead, I think the client should recursively search the discriminator tree to find the correct type. Specifically, here we should look for a match recursively down the discriminator tree. Would that still honor the OAS?

[spacether]

@ethan92429 I won't know until I see an example of your use case. Can you create and share a sample spec?

[eak24]

Example spec:

components:
  schemas:
    Animal:
      type: object
      required:
      - type_key
      properties:
        type_key:
          type: string
      mapping:
        pet: '#/components/schemas/Pet'
    Pet:
      type: object
      properties:
        type_key:
          type: string
      discriminator:
        propertyName: type_key
        mapping:
          cat: '#/components/schemas/Cat'
    Cat:
      type: object
      properties:
        type_key:
          age: number

Now if the client tries to deserialize something that looks like {'type_key' : 'cat'} and it is known to be of type 'Animal', it will just not find the correct discriminated class (the Cat class). To work correctly, it would need to recursively search through all the discriminators of Pet as well. However, I'm not sure this is supported in OAS... Is the right way to solve this by making all my discriminators class-specific? For instance, changing 'type_key' to 'animal_type_key' and 'pet_type_key', respectively? That way an instnance of a Cat would specify both 'animal_type_key' and 'pet_type_key'... Thoughts?

[eak24]

@spacether an example of code that would support this behavior: eak24@f606cfb

[spacether]

Thank you for making that sample. It looks like this issue is unrelated to properties of type self. To help us fix it can you please post it as a new issue?
Should Cat allOf inherit Pet? Shoiuld Pet allOf inherent Animal? Why not combine the Pet and Animal classes?

[eak24]

Yes - all inherit Animal and Cat inherits Pet. This is just the simplest example I could come up with to illustrate the issue - the spec that I'm using is 77,000 lines of JSON, so posting that wouldn't have been helpful :-) . There are many, many examples of this type of inheritance in our codebase. In our homegrown clients, we have a single 'discriminator mapping' dictionary that can relate any of our type mapping key values to their respective type. This way we flatten the type graph and achieve good performance. It would be really neat if there was some way to support this use case. I can write up an issue, but TBH, I'm not sure what the right solution is...

[spacether]

Your posted diff is the right solution. I understand your use case better now. Let's move the discussion there or to an issue if you make it. Either is good.

[eak24]

#4912 is the issue I posted. Moving discussion there.

[wing328]

LGTM