scolvin

would love to see a benchmark where typedload is faster than Pydantic V2. Could you share a link?

This is simply not true. So sad.

We removed benchmarks from the docs completely when the rule of "only show benchmarks with comparatively popular or more popular libraries" no longer made sense, and maintaining benchmarks with many hobby packages was obviously going to become burdensome.

Please show me a sensible benchmark where your library is faster than pydantic?

It's slow with pypy because of some problems with pyo3's interaction with pypy, not a pure python fallback.

I agree unions were wrong in V1, but smart unions helped, and unions are fixed properly in V2.

I agree that pydantic could have been faster while still being written in Python.

The argument for Rust: 1. If I'm going to rewrite - why not go the whole hog and do it in rust - and thereby get a 20x improvement, not 2x. 2. By using Rust we can have add more customisation with virtually no performance impact, with Python that's not the case.

Of course we could make Pydantic faster by removing features, but that would be very disappointing for existing user.

As mentioned by other commenters, your comment about "constrained" does not apply.

More details here https://pydantic.dev/announcement/

Not in detail, but there's more information at

https://pydantic.dev/announcement/

And it would be much more complex to implement, particularly with recursively nested types.

I disagree, this is much less clear. It also don't work well with pytest's error output.

Because even their homepage is down intermittently/for some people.

I don't believe it can be used for previews. Also, it requires an api key, so can't be used on pull requests from forks on github actions.

One of the most useful trick I found was installing the tool via sitecustomize.py so you don't need the import:

    # add devtools debug to builtins
    try:
        from devtools import debug
    except ImportError:
        pass
    else:
        __builtins__['debug'] = debug

(see https://github.com/samuelcolvin/python-devtools#usage-withou...)

This would work with icecream too.

The second advantage of not needing the import is that CI fails if you forget to remove all debug() commands.

Humm, I built a similar but more powerful tool:

https://github.com/samuelcolvin/python-devtools

(install with `pip install devtools`)

It has similar functionality for debugging but has prettier formatting and code highlighting using pygments.

Netlify offers much of the functionality but I hit the monthly build limit long ago for pydantic docs. Plus it's a pain to use for stuff like coverage.

S3 doesn't offer the redirect functionally and you would have to have your aws keys public in the repo.

So not really substitutes.

Dynamic subdomains aren't a problem for this with the smart redirecting logic.

Interesting, I find it surprising there isn't a widely used service with this functionality.

Then luck you can (and I do) run Rust on cloudflare workers :-)

I would argue your case for cloudflare workers being "sketchy" only applies if you're confident you're better at "automate provisioning and configuration" than cloudflare.

In the end you have two choices: run your own hardware and networking, control everything; or, use a "cloud" infrastructure provider and accept you don't really have control.

Once you've given up fundamental control of the hardware networking and OS, I don't really see the advantage of managing provisioning and configuration. I definitely don't see a sensible argument that not doing so is "sketchy".

why are cloudflare workers any more "sketchy" than AWS, azure or GCP?

I don't see what any of this has to do with tracking?

Well the problems with conventional server side rendering (django, jinja, rails) are well documented (they're the reason (in part) people build react, angular etc.):

* UI get's intertwined with logic and DB access * monolithic applications * UI developers have to have access to the full server side application

I guess overall I wasn't suggesting this approach as an alternative to traditional django-eske apps, but rather to CRA-eske single page app platforms.

This is really fun. Thank you.

Thanks for the feedback, I hadn't heard of Iodide.

My number one aim with this was for the code to be kept in a simple text file precisely so things like linters worked out of the box.

I guess other languages would in theory be possible but would take almost as much work as the original implementation.

If you want to encrypt your data before you upload it, surely you have that option? In fact that really the only way it could work, if they did the encryption and have your back the key, you'd have to trust them that they're not keeping it too.

I can understand why they don't want to add a big barrier to entry by requiring that.

Nell health | Full Time | ONSITE | London, UK

Senior frontend developer, react or vue.

Nell is transforming how companies and individuals check, understand and optimise their health by putting positive health data into the hands of every employee. Our industry leading team of scientists have designed unique tests and support programmes, which combine genetic, biomarker and lifestyle data to provide a truly personalised and holistic view of your health.

Nell focus on 'positive' and actionable diet, exercise and lifestyle insights that prevent bad health before it happens. We are driving a revolution in employee engagement and performance, making it easier than ever before for individuals to track and improve their health by engaging with their own bodies.

Be a pivotal part of building our platform to process genetic and biometric data to show people how they can be healthier.

Contact samuel@nell.co.uk

Performance was a slight concern, but more important was correctness.

This used the widely used and very stable toml library from rust.

It started because I tried the most popular toml library for python and found significant bugs and poor code quality. Some other libraries had fewer bugs but were very slow. Then I wondered how hard it would be to use the rust library from python via pyo3, and here we are.

Completely agree.

We use netlify a lot and don't pay, we'd happily pay if there was a reasonable middle way.

1. Type safety!

Run time type hint checks in the standard library, small performance impact allowed.

2. Compilation/optimisation using your hints

Like cython but using python's own type hints so you can give the compiler type information without leaving valid python.

This is absolutely excellent. It's the kind of article I always want to write when I dig into Ubuntu's dark underbelly.

Arguably it might deserve a more descriptive title?

I don't. I'm not sure it would be that interesting.

In short:

* I started out with a class that substituted environment variables into itself for settings, still in aiohttp-devtools: https://github.com/aio-libs/aiohttp-devtools/blob/master/aio...

* using annotations occurred to me

* it worked

* it was 50% faster than trafaret which I'd been using before

* I added some unit tests, published to pypi and started using it.

"faux-immutability" is a good way to describe it. My problem is the "faux"; proper immutability is virtually impossible in python and I'm not convinced about providing partial immutability and thereby giving people a false sense of security. That said there's an issue about it: https://github.com/samuelcolvin/pydantic/issues/38. I'll consider it if we can find a performant and elegant way of using it.

__eq__ makes sense, I'll do it when I get round to it

__hash__ would be nice but far from simple to do in a performant way.

__lt__ I'm not sure what this would mean?

__cmp__ no longer exists in python 3.

Pydantic is not just a toy, I built it having used and abused numerous other libraries and found them wanting in one way or another.

Because it reuses python's typing system it should have the most pythonic and flexible description of types possible.

I agree about the need for complex validation chains relating to numerous fields, that's already partially possible with pydantic (although not documented). I'll add support for this stuff as well as documentation over the next few weeks.

yahoo are dreadful, I suspect you'll have difficulty. Perhaps try finding one of their developers on github and contacting them directly.