141–150 of 194 posts
Earlier quoted context omitted.
That did not change the fact that Java worked perfectly alright on Windows, the same cannot be said for many FOSS languages that insist all OSes are UNIX clones.
Quality chefs don't work for McDonald's, either. :D
Earlier quoted context omitted.
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.
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=...
Earlier quoted context omitted.
That did not change the fact that Java worked perfectly alright on Windows, the same cannot be said for many FOSS languages that insist all OSes are UNIX clones.
Quality chefs don't work for McDonald's, either. :D
Earlier quoted context omitted.
> There is no such thing as a buggy language. How can you know if you don't have a verified formal description of your language's semantics? It's very much possible (and imho even quite likely) that a lot of language definitions are self contradicting. Of course one could argue that such self contradictions aren't "bugs" at all. But such an argumentation would seem very odd, imho, no matter one can actually "define"…
http://blog.llvm.org/2011/05/what-every-c-programmer-should-... > Signed integer overflow: If arithmetic on an 'int' type (for example) overflows, the result is undefined. One example is that "INT_MAX+1" is not guaranteed to be INT_MIN. Probably not what the GP meant, but I think this qualifies as a "buggy language (spec)"
But defining some things in a contradicting manner would make up a buggy spec, I guess.
Regarding the int example, funny enough I made a comment about that just before here:
Earlier quoted context omitted.
Overflowing integers is not a bug. It's literally how an adder circuit operates on fixed precision. Ignoring them by default is worth criticizing but there are plenty of times where silent overflow is correct and desirable behavior.
It's technically not a "bug" in Rust or C++, it's undefined behaviour , which is much worse than a bug! (and it's never correct behaviour)
Earlier quoted context omitted.
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…
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.
Earlier quoted context omitted.
Slightly related question: why do people love Python so much? Or, any dynamically typed language? There's almost nothing that has frustrated me more in a professional setting than trying to figure out what some dynamically typed code is doing and ensuring I don't break anything by making changes.
Anecdote, but I like the Python community's emphasis on "readability counts". I did not get that from e.g. Ruby. Python's internals are also relatively accessible and easy to work with, so it's smooth sailing once you have that need. The language starts out easy, and grows with you. Of the languages I've tried (and there are many), only Smalltalk and the Lisp family were comparable in expressiveness. The language mos…
Earlier quoted context omitted.
Slightly related question: why do people love Python so much? Or, any dynamically typed language? There's almost nothing that has frustrated me more in a professional setting than trying to figure out what some dynamically typed code is doing and ensuring I don't break anything by making changes.
Because you can do a lot with little typing and there are lots of great libraries. Python is probably the best choice when you need to get something done quick or calculate something when performance is not important. It is also not an exotic functional language without loops and filled with linked lists. Also, in Python integers do not overflow, unlike in Rust, C and other buggy languages. If you name a language, wi…
Second I needed to redirect scikitlearn logging to a file. Which did not work because scikit does not use logging but something homegrown. We just overwrite the internal log function and all was good.
Yes it's seldom needed and it's a very sharp sword but it's much better that it's there when you need it. I encountered bugs in .net stdlib which where there was no alternative than to wait for the next release. Very ugly when you need to ship.
At this point I'm open to try anything that will give me access to the python ecosystem without having to code in Python. From the FAQ it looks like Erg code gets transpiled to python bytecode.
Earlier quoted context omitted.
Because you can do a lot with little typing and there are lots of great libraries. Python is probably the best choice when you need to get something done quick or calculate something when performance is not important. It is also not an exotic functional language without loops and filled with linked lists. Also, in Python integers do not overflow, unlike in Rust, C and other buggy languages. If you name a language, wi…
What i don't like about python: The goddamn versioning and packaging problems. About 5 years ago python was incredible. You could pop out a project quickly because there were very few packages that made breaking changes over their development, so you could often use your standard workflow with the set of packages you we're comfortable with, even if there were new versions available that day. Now, Nvidia and Google ru…