4 ms·
I don't even mind (although it bothers me that python doesn't have pipes ala R, or any sort of nice lambda syntax) but I wonder how much work has been put to ta
by JZL003 4y ago
I don't even mind (although it bothers me that python doesn't have pipes ala R, or any sort of nice lambda syntax) but I wonder how much work has been put to take python-like dialect and hammer it over and over into being fast
NumPy giving a whole other set of verbs you have to memorize to just wrap around C, then JAX+etc which take that subset and make it faster, then the pypy+pyston to rewrite big parts, with numba to do individual functions if you really want for loops. I know it's an over simplification and it's all pretty amazing work, but it's exhausting to me how many companies and people have put work into taking a fast language and trying to make subsets fast
- tpoacher 4y agore "pipes" (or, chain operations) in Python, here's my personal approach that I use: https://sr.ht/~tpapastylianou/chain-ops-python/ https://sr.ht/~tpapastylianou/chain-ops-python/ It's clean, works well, it's debuggable ... having a special operator might have been nice syntactic sugar, but isnt really necessary.
- packetlost 4y agoYeah. Python is a great language for glue. Glue does not need to be fast, it's hopefully small in scope, and it has (hopefully) one or few jobs. Python can be a great frontend to faster C code, but sooner or later it starts being the bottleneck where it matters. These pseudo-Python compiler/interpreters are... cool, I guess, and might even solve that problem in some cases. The issue is half of them target the syntax of Python, rather than integrating with the runtime (really, CPython). The problem, I think, is that we have huge applications implemented from top to bottom in Python where the bottleneck is... everywhere and there is no good solution that isn't somehow writing a faster Python implementation (Pypy will get you far) or rewriting it all in a different language.