Hacker News Reader

Comment by Arbortheus | Hacker News Reader

It would be nice if someone created a typescript for python. Something that allows us to wrangle control and sanity over reams of legacy untyped python madness.

View on HN

I think both `erg` and statically typed Python are both attempts at doing exactly that.

May be what you mean is a static typing solution for Python whose syntax is a superset of Python syntax (which I don't think `erg` is), but isn't identical to Python's syntax( ie, it is a strict superset, which statically typed Python's syntax isn't). Typescript is exactly that for JS.

In that case, I agree with you that such an attempt would indeed be very interesting because it would allow for more aggressive exploration of ergonomic typing constructs while maintaining that any valid Python would be valid in that new language as well (just like TS).

Related question, how does typescript’s gradual typing system work? Are there any resources on how they implemented and architected it?

As others have mentioned, one can get some types in python through its own typing module and use a combination of tools for type enforcing and editor intellisense (mypy, pylance, etc.).

However what I’m missing is having more advanced type constructs. For example mapped types, lookup types, etc [1].

That said, it seems like python devs keep adding features over time. For example a couple of years ago it wasn’t possible to specify which fields of a dictionary are required and not required (it required putting required fields in one TypedDict and then subclassing it into another one that had the non required ones with total=False), nor it was possible to “spread” a TypedDict to declare the kwarg types in a function.

[1]: https://www.typescriptlang.org/docs/handbook/release-notes/t...

And while they're at it, can they unify the pip, egg, conda, miniconda, apt-get dependency management madness? If we're putting in requests for miracles, that's mine.

Mypy is basically that.

https://github.com/python/mypy

Also note that while this repo might look like a third party bolton (it started that way), the type hinting syntax is nowadays actually integrated in the language.

The only thing you need to do is add appropriate type hints at function definitions and then run mypy in your build and CI and you got something that checks basically as strict as Java.

For those saying it’s optional so can’t be trusted, consider that compiling C++ with -Wall -Werror is also optional… adding it is simply part of standard project hygiene.

Pylance in VSCode also errs on type mismatches.

> The only thing you need to do is add appropriate type hints at function definitions and then run mypy in your build and CI and you got something that checks basically as strict as Java.

There's another comment making this claim elsewhere and I wonder if perhaps those assertions are coming from someone who doesn't write Java, or if my experience with mypy is just especially bad

I'll also point out that easily 90% of my heartburn with trying to typehint python in legacy projects is that python seems to encourage so much introspection and namespace trickery. It feels to me like the mypy audience is saying "well, there's a staticly typed language hiding in python so just don't use unsafe parts of the language and you'll be fine"

If it's anything like TypeScript, you can add type documentation for all the tricks.

why not use the built in typing? https://docs.python.org/3/library/typing.html

it doesnt enforce the types in any way

You can run, for example, pre-commit checks such as mypy to enforce some semblance of sanity.

Neither does typescript. All the types are removed at runtime, it's up to you to ensure that your build process and tooling correctly validates the types. The same is true for python, and the ecosystem has really great tools for doing this.

Use pydandic for serde/IO validation, and mypy --strict. And minimize cheating e.g. Any. I think you'll find it extremely stable and a totally different beast than usual python.

I wrote typedload before pydantic was a thing. It's faster and actually works well with mypy and python's type system.

Pydantic requires inheritance and requires a modified mypy because it uses types its own way rather than the python way.

Oh, typedload is faster than pydantic, despite being pure python instead of an .so file.

I would be very interested in seeing some benchmarks!

I'm pretty sure that serde, the rust library that Pydantic uses, is faster than the JSON parser written in C in the python standard lib, so I'd be very surprised if your pure python validation library beat pydantic.

https://ltworf.github.io/typedload/performance.html

At the bottom there are instructions on how to run the benchmark locally.

I read more about your repo, and it looks like typedload only does Python lists/dicts -> typed python objects(like named tuples, data classes, attrs classes, etc). Ie, the benchmarks don't include the time required to parse the JSON.

So I modified the benchmarking code to include loading JSON[0], and your library still came out on top!

But, it turns out I was wrong about pydantic using serde under the hood. Pydantic version 2 will. And the maintainer aims for it to be about 10x faster [1] than version 1.

Nonetheless, this was definitely a surprise for me, and if I ever go back to using Python, I'll definitely check your library out!

I'm curious, why do you think pydantic took off and your library didn't? It looks like your library is both faster and easier to use to me.

[0] https://github.com/davidatsurge/typedload/pull/1/files?diff=...

[1] https://github.com/pydantic/pydantic-core#pydantic-core

But you could use whatever module to load json and then use typedload.

Having them integrated could be advantageous to save memory and avoid loading the full json first. Like loading the objects directly to their final destination as the json gets parsed. But that would be kinda complicated.

I have absolutely no idea why mine isn't so used, but my model of GPL license + pay me to get LGPL license probably doesn't help. But is not a factor if used for internal stuff.

apischema is my second favourite one and it also doesn't have many users. However it came later so that's an easier explanation.

I recently tried a similar library called jsons. I wanted to benchmark it but it was too buggy to do a meaningful comparison. Of course it has 8x more downloads :D I guess the users either have very basic use cases or prefer working around the issues rather than trying a different library.

Finding a decent library is not easy. I'm trying to convince my coworkers to just drop and rewrite a bad golang library they are using and working around a lot.

Ahh. It would be the license if I were to make the decision. Only because, if I were to use Python, performance must not be a big concern, so I would go for an alternative (albeit slower) library (which there isn't a shortage of) instead of paying for the non GPL license.

I think something else that might help is if you make it more prominent (if it's visible right now at all, since I can't find it) the message that tells people, at least, "contact me to arrange a different license", or at best, a pricing model.

> I would go for an alternative (albeit slower) library

Well now in 2022… in 2018 there was nothing else. It was (and still is) the only option on python 3.5 AFAIK.

Thanks for the advice, I guess I can put something about that.

Mypy?

Reply on news.ycombinator.com