TL;DR: opt-in flag to accept unescaped control chars (e.g. a bare newline)
inside strings, mirroring stdlib json's strict= — default behavior and
spec-compliance untouched. I'll write it; just want a 👍/👎 before I sink
time in. No reply needed either way: a 👍, or silence past ~2 weeks, I'll
take as a green light to send a small draft PR (loads() only,
strict=True default) for you to review whenever's convenient. An explicit
comment is a stop sign. Feel free to just close this if it's not wanted.
Why: pyjson5.loads('"foo\nbar"') (a literal newline byte, not the
two-char \n escape) raises Json5EOF. I know 1.4.7 made this rejection
deliberate, "per spec" — not disputing that default. My case: real files
from a shipping system whose own runtime parses them as-is, bare newlines
included — not malformed/legacy data, just not spec-pure JSON5.
Why this stays out of your compliance/correctness/security bar:
- Default unchanged — new kwarg defaults to today's strict behavior, so the
"all valid JSON5/JSON can be read" guarantee is untouched.
- Decode-only —
encode_*() and its HTML-safety escaping are untouched.
- Documented as an explicit spec deviation when enabled, same caveat stdlib
json gives for its strict flag.
- Precedent: the pure-Python
json5 package (dpranke's, on PyPI as
json5) already has this exact strict kwarg/semantics — matching an
existing convention, not inventing one.
TL;DR: opt-in flag to accept unescaped control chars (e.g. a bare newline)
inside strings, mirroring stdlib
json'sstrict=— default behavior andspec-compliance untouched. I'll write it; just want a 👍/👎 before I sink
time in. No reply needed either way: a 👍, or silence past ~2 weeks, I'll
take as a green light to send a small draft PR (
loads()only,strict=Truedefault) for you to review whenever's convenient. An explicitcomment is a stop sign. Feel free to just close this if it's not wanted.
Why:
pyjson5.loads('"foo\nbar"')(a literal newline byte, not thetwo-char
\nescape) raisesJson5EOF. I know 1.4.7 made this rejectiondeliberate, "per spec" — not disputing that default. My case: real files
from a shipping system whose own runtime parses them as-is, bare newlines
included — not malformed/legacy data, just not spec-pure JSON5.
Why this stays out of your compliance/correctness/security bar:
"all valid JSON5/JSON can be read" guarantee is untouched.
encode_*()and its HTML-safety escaping are untouched.jsongives for itsstrictflag.json5package (dpranke's, on PyPI asjson5) already has this exactstrictkwarg/semantics — matching anexisting convention, not inventing one.