This looks great OP. Do you have anything on the roadmap that you’d be open to receiving PRs for? I noticed there weren’t any issues in the repo and would be keen to lend a hand!
Pydantic is great lib and and has many advantages over Jsonic,
I think main use cases for Jsonic over Pydantic are:
- You already have plain Python classes or dataclasses and don’t want to convert them to BaseModel
- You prefer minimal intrusion - no inheritance, no decorators, no schema definitions
- You need to serialize and deserialize Pydantic models alongside non-Pydantic classes
Having said that, Pydantic is the better choice in most cases.
This is also why Jsonic integrate natively with Pydantic so you can serialize Pydantic models using Jsonic out of the box
I can see that. Pydantic is great but relatively slow (which matters on edge devices) and can be bloated.
The fact that all your projects use Pydantic makes it an easy starting point and created standardisation - of course.
Nevertheless, I can definitely see some use-cases for lightweight JSON-serialisation without bringing in Pydantic. Dataclasses are great, but lack proper json handling.
This! People underestimate the extent to which lawyers are negotiable also. “I’m not paying that” is a surprisingly effective method; they’re often willing to compromise on payment terms, work at-risk subject to a successful outcome, significantly reduce their rates, etc.
In my experience, most people underestimate what's negotiable across the board. Especially those making enough to do most of their business with mass-market operations, like big-box stores and retail service providers, that profit by doing many, many standardized transactions every day, with minimal discretion or even personal involvement.
Below that, lots of haggling and informal trade often help people get by. The costs of that process can be another burden on the poor. At the high end, it's worth involving people with discretion on the sell side. Additionally, sales are often one-off and customized. They may also bundle a bunch of different items and benefits without clear line-item breakdowns.
When hiring a lawyer, I'd nearly always recommend getting terms down in a written and signed engagement letter before work starts. That is very much a negotiation, but it's fine to ask questions and comparison shop.
If you're starting with a call, it's perfectly normal to start by asking whether initial consultation will be billed or not. If it will be, ask the rate. If it won't be, expect some limits on what can be discussed. The best lawyers I know aren't cheap or easily tricked into giving free advice on consultation calls with speedrunners, but they are up-front about what they charge for and how.
I actually really like Elasticsearch. It’s very powerful, there’s a healthy ecosystem of tools (increasingly for OpenSearch too), and the query language makes sense to me.
Sure it’s computationally expensive, inefficient even, but for many use-cases it just works.
I’d add that for production deployments, AWS has developed a new instance family that enables OpenSearch data to be stored on S3 [1], bringing significant cost savings.
From my limited interactions with document-intensive sectors (i.e. legal), I think they’re sorely lacking something like this.
When the same document is edited by two separate individuals and diverges, it is a nightmare to reconcile the two.
I truly wish (i.) Microsoft Word was a nicer format for VCS, or (ii.) Markdown was more suitable for “formal” legal texts and specifications — probably in that order (!)
*According to a leaked diplomatic cable: https://www.axios.com/2018/01/05/declassified-cable-estimate...
reply