allow Feature **id** to be either a String or a Number

[vincentsarago]

closes #90

I'm a bit hesitant on this because pydantic smart-union is slower https://docs.pydantic.dev/usage/model_config/#smart-union

Maybe we can wait for pydantic v2 🤷

[eseglem]

I just realized this could use "Strict" types instead of dealing with smart union. Could even say that is more correct if the goal is to strictly enforce the GeoJSON spec. With the current Optional[str] bad inputs (bool, float) can be coerced to a string without errors. Whereas we remove the weird behavior and we don't coerce int to str if we do this instead:

from pydantic import StrictInt, StrictStr
...
    id: Optional[Union[StrictInt, StrictStr]] = None

And yes, v2 of pydantic is supposedly just around the corner, but I think this could be the right route to go even once v2 is out.

Probably worth a look to see if there is other places where use of "Strict" could be useful as well.

---

With smart union you can still do weird stuff. Especially since bool is a subclass of int in python.

>>> class Foo(BaseModel):
...     bar: int | str
...     class Config:
...         smart_union = True
... 
>>> Foo(bar=3)
Foo(bar=3)
>>> Foo(bar="a")
Foo(bar='a')
>>> Foo(bar=False)
Foo(bar=False)
>>> Foo(bar=3.14159)
Foo(bar=3)
# Flipping order
>>> class Foo(BaseModel):
...     bar: str | int
...     class Config:
...         smart_union = True
... 
# The rest are the same
>>> Foo(bar=3.14159)
Foo(bar='3.14159')

Whereas with "Strict" types, they have to be the exact types.

>>> class Foo(BaseModel):
...     bar: StrictInt | StrictStr # Order doesn't matter here
... 
>>> Foo(bar=3)
Foo(bar=3)
>>> Foo(bar="a")
Foo(bar='a')
# Both of these produce the same error
>>> Foo(bar=3.14159)
>>> Foo(bar=False)
# Which I think is probably the most accurate enforcement of the spec
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "pydantic/main.py", line 341, in pydantic.main.BaseModel.__init__
pydantic.error_wrappers.ValidationError: 2 validation errors for Foo
bar
  value is not a valid integer (type=type_error.integer)
bar
  str type expected (type=type_error.str)

[vincentsarago]

🙏 thanks @eseglem, will switch to strict

[eseglem]

LGTM whenever it stops complaining about stuff.

[vincentsarago]

🤦 I messed up my branch sorry

[bluenote10]

According to the specs the id is a number, which in JSON terminology should include float as well, no? It is probably not the best idea to use floats as an id, but if the specs allow it, the model should probably not reject it?