tefra / xsdata

Naive XML & JSON Bindings for python
https://xsdata.readthedocs.io
MIT License
324 stars 59 forks source link

self-referencing field - original case recursion error #1015

Closed dsfaccini closed 5 months ago

dsfaccini commented 5 months ago

Hi @tefra,

Working on this same project I wanted to use originalCase for both the Class names and the Field names. The reason is, I already have a partial code base using the original names (in PascalCase) and mapping these existing functions to generated snake_case Class and Field names is a whole chore.

So I modified the xsdata init-config file to preserve the case and I got a recursion error on the last step of generation.

    <!-- <ClassName case="originalCase" safePrefix="type"/> -->
    <!-- <FieldName case="originalCase" safePrefix="value"/> -->
  File "C:\Users\dsfaccini\AppData\Local\Programs\Python\Python311\Lib\dataclasses.py", line 284, in __repr__
    return ('Field('
            ^^^^^^^^
  File "C:\Users\dsfaccini\AppData\Local\Programs\Python\Python311\Lib\typing.py", line 1643, in __repr__
    return f'typing.Optional[{_type_repr(args[0])}]'
                              ^^^^^^^^^^^^^^^^^^^
  File "C:\Users\dsfaccini\AppData\Local\Programs\Python\Python311\Lib\typing.py", line 242, in _type_repr
    return repr(obj)
           ^^^^^^^^^
RecursionError: maximum recursion depth exceeded

Based on ./generation.log lines 70 to 145, I'm guessing the recursion error comes from a field name referencing itself in its type. If that's the case this should be easily fixable.

You can try it by cloning this repo and running the generate script.

Potential underlying issue

Also, if you look at the generated module you'll see the following on line 259

    Context: Optional[Context] = Field(...

This messes up Pylance/Pyright, since it recognizes this as the field referencing itself. Variable not allowed in type expression *Pylance*(reportInvalidTypeForm) The correct generation in those cases should be

    Context: Optional['Context'] = Field(...

Let me know if you'd like me to put up a pull request to adjust this behavior! It would be helpful in that case if you could nudge me a bit on what file/s to look into.

Best regards, David

dsfaccini commented 5 months ago

Ok I've encountered a case where the field type is correctly wrapped in quotes, but the name of the field is the same as a subclass defined inside the class and that is just not something the library should be responsible for, so I'm closing my issue.

An example to illustrate here

Best David