Ahhh, Vaxman still up to his usual shenannigans :-)

Imagine that, a self-organizing, self-learning software that builds its own hardware. Even dumb primates like us can build ‘em!

I've had exactly the same situation, ~2M MAU service with REDIS as the only persistence system, all data being JSON serialized Pydantic models. The storage overhead was just terrible and cost real money.

This would have been a super nice to have back then.

I wonder though how much sense it would make to get something like this mainlined into upstream Pydantic? as having this downstream would give many continuity and dependency lock concerns. And having it as part of the main library would significantly drive adoption rate.

Thanks, your Redis story sounds exactly like my motivation. When the cache layer becomes the primary persistence and you’re pushing around millions of JSON-encoded Pydantic objects, the overhead hits both RAM and the bill very quickly. That pain is real.

Regarding getting this into Pydantic core: I doubt the maintainers would want to ship and maintain a binary serialization layer inside the main project. That said, it might still be worth opening an issue to hear their perspective - worst case, it becomes a documented "won’t include".

As for continuity and lock-in concerns - my primary production workload depends on this library, so I fully intend to keep it updated alongside new Pydantic and Python releases. I also intentionally designed it with minimal dependencies: core functionality uses only pydantic and typing-extensions. The only extra is leb128, and that’s just for UInt128, which almost nobody truly needs - I’m considering moving that to an optional extra to keep the base install even leaner.

Found in issue where maintainer answered that they are only going to support JSON

https://github.com/pydantic/pydantic/discussions/4097

The answer honestly feels a bit lacking, and evasive.

How is the write support now-adays, is it production quality now?

I used Kaitai in a IoT project for building data ingress parsers and it was great. But not having write support was a bummer.

I honestly zoned out when I saw how many and what steps where required before just wget'ing a image file.

Sorry, nope.

Yeah, I get that and appreciate it. I feel the same way. We're working on changing it to be a 1-click process.

Well....toml isn't that much more than .ini files slightly brough up in feature support.

Again not great for bigger documents.

This also seems a bit like AWS Chalice reinvented, which might be a good thing as AWS has silently abandoned it.

Great read, but I honestly had wished the author had split it into several separate articles.

I had this literally happen to me a couple of months ago.

Slacking off while waiting for some performance tests to run (Shoutout to Locust.io!) with my big 27" screen full of terminals for each runner, server logs etc.

...And then on my laptop screen I honestly was just slacking off and reading Reddit.

'VP Of Technology' comes over "I dont know what you are doing, but it's the most impressive thing I've seen in a while".

...Yes sir!

Provision a VPS/VM/Cloud instance/etc, install your dev tools on it and use it over mush.

And remember for things like looking up git commands or even a lot of your dependency documentation, you do not need a web browser. Git comes with manpages, many libraries will have docs in .md or whatever in them.

....Atreides Management?

The financing arm of a aristocratic line running a personality cult and who have a nepo baby on the cards contemplating a little bit of jyhad as his ticket out?

....I Do sometimes wonder who comes up with these names.

The same type of people who name their companies Palantir and Anduril

Maybe they should be called the Nazgul.

And cross swords with IBM's legal department? No thanks.

> I Do sometimes wonder who comes up with these names.

The same kind of people that idolize the character Patrick Bateman from American Psycho instead of laughing at how ridiculous and pathetic Bateman is.