xs:int value filled with "1.0" (expected: "1")

[fvkluck]

Hi,

First of all, thanks for creating and maintaining python-zeep.

Recently at work I ran into an issue where an xs:int typed value ended up filled as "1.0". This seems to me incorrect, and the little exact specification I could find on the internet seems to agree that the decimal point should not be a part of the int (e.g. here). We're on zeep version 4.2.1.

I've looked into the source code, and I think I've found the source of this behavior here:

class Integer(Decimal):
    _default_qname = xsd_ns("integer")
    accepted_types = [int, float, str]

    def xmlvalue(self, value):
        return str(value)

    def pythonvalue(self, value):
        return int(value)

The accepted python types for the xs:int are the int, float and str (makes sense), but then it is transformed into xml using 'just' str(value).

If you agree with the analysis, I think I can find the time to create a PR (including a minimal example/test). So some questions:

1. Do you agree that the "1.0" should be a "1" for type xs:int?
2. Do you have a preference for the behavior regarding xs:int's being filled from floats? Some ideas I have:
   a. Raise an error (reasoning: it's better for the consumer of the library to actively decide how to transform the float into an int)
   b. Just cast it to an int first (reasoning: most likely the value is correct, and it's just the type that's incorrect)
   Personally I lean towards idea a.

If you can let me know if it's worth spending time on (i.e. a PR would have a chance of being accepted), I'll start experimenting locally and fixing it.

Best,
Florian

[fvkluck]

I just realised that both of my suggestions could be considered breaking changes, and would ruin the fun for anyone relying on the float getting an xmlvalue of "1.0" instead of "1". Or anyone that sends the soap request to a service that doesn't mind the "1.0".

The issue feels a bit minor for a breaking change.

So then I guess the ideas I have are:
c. keep current behavior, but log a warning
d. Introduce a setting/feature flag that enables this behavior and defaults to False. But that's a lot of work + additional maintenance for this issue
e. Do nothing

c and e seem the only reasonable ones