You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The generated type for Root.first is overly permissive. From a static typing perspective, it allows tuples of arbitrary length, which is incorrect. Arguably, the type of Root.first here should either be tuple[()] | tuple[str] | tuple[str, str] or None | tuple[str] | tuple[str, str]. Python doesn't currently support fixed-length homogeneous tuples (see python/typing#786), but with code generation xsdata could simply construct the long union type for any finite maxOccurs. An issue arises when both minOccurs > 0 and maxOccurs = 'unbounded'. To my knowledge, there's no mechanism to deal with such cases properly in Python, so using tuple[T, ...] seems like a reasonable fallback.
When the maxOccurs = 'unbounded', the type tuple[T, T, T, *tuple[T, ...]] should be used where the initial T is repeated minOccurs times or simply tuple[T, ...] if the minOccurs = 0.
<xs:sequence> isn't occuring exactly once
Unless <xs:sequence> has both minOccurs = 1 and maxOccurs = 1, every child of a sequence is meant to repeat the same number of times. Here's an example schema:
class Root:
first_child: tuple[str, ...]
second_child: tuple[str, ...]
The problem here is twofold:
These types are once again needlessly wide as they don't reflect the maxOccurs="2" constraint.
These types don't reflect that first_child and second_child can only repeat the same amount of times.
I propose, that xsdata should instead treat the single occurrence of <xs:sequence> as a separate type and all repetitions should apply to that type according to the rules outlined in the first section of this issue. For example, the above schema would roughly translate to:
class RootSequence:
first_child: str
second_child: str
class Root:
sequences: tuple[()] | tuple[RootSequence] | tuple[RootSequence, RootSequence]
The text was updated successfully, but these errors were encountered:
sashkent3
changed the title
Strict-ish static typing when maxOccurs > 1 or <xs:sequence> isn't occuring exactly once
Strict static typing when maxOccurs > 1 or <xs:sequence> isn't occuring exactly once
Mar 1, 2025
This issue is about improving static types which
xsdata
generates so that they reflect the original schema more precisely.maxOccurs
> 1Consider the following schema:
Here's a piece of code
xsdata
generates from it:The generated type for
Root.first
is overly permissive. From a static typing perspective, it allows tuples of arbitrary length, which is incorrect. Arguably, the type ofRoot.first
here should either betuple[()] | tuple[str] | tuple[str, str]
orNone | tuple[str] | tuple[str, str]
. Python doesn't currently support fixed-length homogeneous tuples (see python/typing#786), but with code generationxsdata
could simply construct the long union type for any finitemaxOccurs
.An issue arises when bothminOccurs
> 0 andmaxOccurs
= 'unbounded'. To my knowledge, there's no mechanism to deal with such cases properly in Python, so usingtuple[T, ...]
seems like a reasonable fallback.When the
maxOccurs
= 'unbounded', the typetuple[T, T, T, *tuple[T, ...]]
should be used where the initialT
is repeatedminOccurs
times or simplytuple[T, ...]
if theminOccurs
= 0.<xs:sequence>
isn't occuring exactly onceUnless
<xs:sequence>
has bothminOccurs
= 1 andmaxOccurs
= 1, every child of a sequence is meant to repeat the same number of times. Here's an example schema:And here're the types
xsdata
generates:The problem here is twofold:
maxOccurs="2"
constraint.first_child
andsecond_child
can only repeat the same amount of times.I propose, that
xsdata
should instead treat the single occurrence of<xs:sequence>
as a separate type and all repetitions should apply to that type according to the rules outlined in the first section of this issue. For example, the above schema would roughly translate to:The text was updated successfully, but these errors were encountered: