Added Python implementation fastjsonschema

[horejsek]

No description provided.

[Relequestual]

Thanks for your hard work on your library.
I'd like to make a suggestion before I merge:
JSON schema says you can use keyword default for providing default values. This implementation uses that and always returns transformed input data.

This is non ideal, as it's non standard.
For clarity, does it mutate the given data or only return the transformed version?

[horejsek]

It mutates the input data. I know it's not good, but it's faster then do the copy all the time. Usually this is not a problem so I decided to keep it fast and write it to the documentation.

[Relequestual]

In that case, I'm afraid I don't feel I can add it to the listing.
Validation should not modify your data unless you explicitly ask for more than validation.
Let me know if you decide to change this. =]

[horejsek]

It is done when explicitly asked. When the default feature is not used, it does not modify the data. :-)

[Relequestual]

When you say

When the default feature is not used

Do you mean when the default keyword in a schema is not used?
It's fine if it returns modified data, but NOT OK if it mutates the input data.
See the difference?
Which is it?

[horejsek]

Yes, I mean when the default keyword is not in the schema.

I know it's not OK. :-) The decision here is done to keep it fast. The copy of the input data would slow the validation down a lot. Usually it's not a problem with the input data, actually it could be even a feature because it's better to not work with the raw input data anyway. If someone wants to keep the input data, he or she can easily duplicate it before the validation. The information about this behaviour is documented.

But if this is blocker to have this library listed, well, don't merge it then. I just thought it would be good to have it here when someone is looking for some fast implementation, because many people do.

[Relequestual]

You've chosen to implement something not in the specification (mutating the input based on default) and claimed you don't want to remove it because it makes it faster.

Mutating the input data should be considered harmful unless it's something the user explicity asks to happen, otherwise they may be in for a nasty supprise!

You've made an assumption about the schema authors purpose for using an annotation of default, and document or not, you're imposing that as a default behaviour, rather than optional.

Do you see why this is likely to be a problem for many users?

Let me know if you decide to amend your implementation to follow the specification.

[handrews]

I think it is reasonable that we require implementations to at least offer a strictly compatible option. We do allow implementations that are incomplete, but not that contradict the spec.

@horejsek if you were to offer an option to either write in or ignore the value of the default keyword, (which should itself default to strict compliance with the spec) then we would list your implementation. Many implementations do exactly this- offer default rewriting as a nonstandard extension, and that's fine.

[Julian]

Something here reads to me like a misunderstanding...

@horejsek you're aware that default isn't supposed to do anything right? It's hard to be faster than "do nothing" :) and when you say:

The decision here is done to keep it fast. The copy of the input data would slow the validation down a lot.

It reads a lot like you've misunderstood -- the choice isn't "mutate or not" -- the overall process of validation neither mutates its input nor generates any return value in any current draft.

Just want to make sure you understood that and recognize that the behavior supposedly implemented and being discussed here is entirely a new feature (one against the recommendations of the spec).

Apologies if I've misread things, but yeah that is how these comments read to me.

[handrews]

Thanks, @Julian , that's a good explanation.

[horejsek]

you're aware that default isn't supposed to do anything right? It's hard to be faster than "do nothing"

@Julian Well, yes and no. In the specification is this sentence:

This keyword can be used to supply a default JSON value associated with a particular schema.

I understand it as it can be implemented or cannot. I decided to include it in the library as it's a nice feature and for speed optimisations (which is why I wrote my library in the first place) do what you don't like here at all. I don't like it either, but still I think it's good trade-off.

So, the default should do nothing in all implementation or how is it meant? Maybe would be good to better explain purposes of it in the specification itself. I use the following link, is it the good one?

https://json-schema.org/latest/json-schema-validation.html#rfc.section.10.2

[handrews]

@horejsek unlike the capitalized MAY, SHOULD, and MUST, which have precise meanings defined by RFC 2119, lowercase "can" does not carry any sort of requirements. It's just an observation that it's possible to do something- in this case, it's talking about what sort of additional usage on top of a JSON Schema implementation is possible. So you can offer it as an extended feature that users can turn on (and many implementations do). But it is not part of the actual specification requirements, and doing it automatically means you are not in conformance.

[horejsek]

Ok. I will add the option to turn it on or off. Is OK for you to have strict version disabled by default? I would like to not do breaking change.