Repository navigation
pydantic 2.x issues #141
Description
Activity
Hi @dixonwhitmire, and anyone still watching this repo —
I'm picking this up. The library is the only typed, multi-transaction (837P/837I/835/834/270/271/276/277) Python X12 SDK I know of, and it deserves to keep working on current Python and Pydantic. Since the org has been quiet since 2022, I've forked it as owgreen-dev/x12sdk and will maintain it there under a new name (Apache-2.0 §6 — the LinuxForHealth and IBM marks stay with their owners; LICENSE and a NOTICE crediting this project are preserved).
Plan, in order: keep the existing test suite as the oracle, add a byte-for-byte round-trip test over all sample files, port to Pydantic v2 + Python 3.10–3.13, drop the experimental FastAPI endpoint (SDK + CLI only), fix the 834 managed-care parse defect and the 835/837I loop-initializer gaps, then publish to PyPI as
x12sdkwith a migration note forlinuxforhealth-x12users.Dixon — you built this; if you'd like a maintainer role, a credited advisory role, or just a heads-up before the 1.0 release, say so here or open an issue on the fork. If IBM/LinuxForHealth would prefer the fork be referenced from this README, I'm happy to send that PR.
Thanks for the years of work in here.
— Oscar (owgreen-dev)
- added a commit that references this issue
on Sep 19, 2026 Hi @dixonwhitmire, and anyone still watching this repo —
I'm picking this up. The library is the only typed, multi-transaction (837P/837I/835/834/270/271/276/277) Python X12 SDK I know of, and it deserves to keep working on current Python and Pydantic. Since the org has been quiet since 2022, I've forked it as owgreen-dev/x12sdk and will maintain it there under a new name (Apache-2.0 §6 — the LinuxForHealth and IBM marks stay with their owners; LICENSE and a NOTICE crediting this project are preserved).
Plan, in order: keep the existing test suite as the oracle, add a byte-for-byte round-trip test over all sample files, port to Pydantic v2 + Python 3.10–3.13, drop the experimental FastAPI endpoint (SDK + CLI only), fix the 834 managed-care parse defect and the 835/837I loop-initializer gaps, then publish to PyPI as
x12sdkwith a migration note forlinuxforhealth-x12users.Dixon — you built this; if you'd like a maintainer role, a credited advisory role, or just a heads-up before the 1.0 release, say so here or open an issue on the fork. If IBM/LinuxForHealth would prefer the fork be referenced from this README, I'm happy to send that PR.
Thanks for the years of work in here.
— Oscar (owgreen-dev)
Hi Oscar/@owgreen-dev,
First and foremost, I am happy to hear that you have found this repo helpful. That's one of the reasons why we built LinuxForHealth—to provide developers with comprehensive tooling for healthcare. It's exciting to see that you are able to move the project forward.
For context: the LinuxForHealth ecosystem and organization were designed by @tedtanne during his tenure as CTO at IBM Watson Health, where I served as the lead engineer for the x12 library. Once IBM divested itself of Watson Health and it became Merative, we stopped active development on the project.
To answer your questions:
- Submitting a PR: Yes, if you wouldn't mind creating a PR that references your active fork, I think that would be very helpful for folks looking for a reliable, Python-based X12 parser.
- Future collaboration: I will star your repo, and if I have the bandwidth to help out, perhaps we could discuss a maintainer role or some other form of contribution in the future.
Finally, it would be great to connect with you to see what you have in mind for the library. If you have the time, you can find my LinkedIn info on my GitHub profile.
Thanks!
DixonThanks Dixon, and thanks for the background — I hadn't realised @tedtanne's ecosystem work sat behind this, or that you were the lead engineer on the x12 library specifically. That context is genuinely useful for how I write up the project's provenance.
PR sent: #142. It adds a short note near the top of the README pointing at the fork, nothing else.
Where the fork stands, so you know what you'd be putting your name near:
- The Pydantic v2 port is merged, on Python 3.10–3.13. Your test corpus is the reason that was safe to attempt — I added a sweep that parses, validates and re-serializes all 67 sample files and asserts the output is byte-identical to the input, and it stayed green through the whole migration.
- That sweep also turned up a few things worth mentioning: the 834 LX loop raised a
TypeErrorfrom a membership check against the parser context, loop 2440 (LQ/FRM) and 4010 loop 2305 (CR7/HSD) had models but no loop initializer so their segments were dropped, andIdcSegment.identification_card_countwasOptional[int] = conint(gt=0)— a type in the default slot, so the bound never applied. All fixed, each with a regression sample. - Added the
py.typedmarker, which was never present, so type checkers now actually see the annotations. - CI runs the matrix plus CodeQL and a dependency licence check.
Next is a 1.0 release to PyPI, then a denial-analytics layer over the 835 models (CAS/CARC/RARC extraction and payer × reason aggregation) for fraud and abuse work, which is the domain I come from.
A maintainer role is open to you whenever you want it, with no expectation of time — having the original author able to weigh in on intent would be worth a lot on the X12 semantics alone.
On connecting: I'm not on LinkedIn, but I would genuinely like to talk through where the library goes. Happy to do that here, or in issues or discussions on the fork, whichever is easiest for you.
Thanks again for taking the time to reply.
— Oscar (owgreen-dev)
- added a commit that references this issue
on Sep 19, 2026
Seeing that this project's setup.cfg has:
pydantic >= 1.9And starting with (I think) Pydantic 2.0, BaseSettings was moved to the pydantic-settings package.
mostly just submitting this to have the pydantic dependency have an upper bound that excludes pydantic 2.x. I may some day help with this project, and submit a PR to migrate this to pydantic 2.x, though don't have the time right now.