Implement 'type' field in problem.yaml from 2023-07-draft spec #421
Conversation
Note that the spec is not fully implemented yet. At least, `validation` will be replaced with `type` in #421.
mpsijm
force-pushed
the
problem-type-from-spec
branch
2 times, most recently
from
3a63b4c to
5572b74
Compare
There was a problem hiding this comment.
I think I'm done implementing type from the new spec 😄 There's two things I'd like to discuss, see the comments.
For the review: the largest change is that ProblemSettings.validation is no longer exposed, since this only works for legacy problems. Instead, the parsing of validation (for legacy) or type (for 2023-07-draft) now only happens in the constructor of ProblemSettings, resulting in three booleans in both ProblemSettings and Problem: interactive, multi-pass, and custom_output. The boolean custom_output is true for interactive, multi-pass, and problems with output_validators/. In other words, custom_output is only false for problems that use the default output validator.
Any other thoughts @RagnarGrootKoerkamp @mzuenni? 😄
mpsijm
force-pushed
the
problem-type-from-spec
branch
from
5572b74 to
907237b
Compare
…tput_validator/)
… type is interactive and/or multi-pass
As promised in #419 (comment), here's an implementation of the
typefield inproblems.yamlfor2023-07-spec😄There's still two
TODOs I want to tackle before merging, but at the very least I can test this setup when working on the Freshmen Programming Contests now 🙂