71–80 of 109 posts
Does anyone have any personal experience in applying mypyc on type-hinted, but otherwise not specially optimized python code? I'm especially interested in what kind of performance speed-ups could be achieved.
> Unlike Cython, mypyc doesn’t directly support interfacing with C libraries or speeding up numeric code. I'm not sure I understand that part of the mypyc documentation ( https://mypyc.readthedocs.io/en/latest/introduction.html#why... ). Does that mean that you can't use something like numpy at all?
Not to be shit-eating, but I never understood why people use python instead of Go other than for ML teams. I program mostly in Java and Go so would love a perspective.
I've been typing SQLAlchemy for some months now and there's lots of scenarios where if you end up on mypy's issue tracker (which is very often), you will see "oh use a #type: ignore to deal with this occasional use case" as official advice. And here we see a compiler that considers all "# type: ignore" to be bugs and will eventually refuse to compile them. That's simply not realistic for the way Python typing works r…
mypyc has escape hatches, e.g. casting to Any is a common trick.
here's a list of 41 issues where either the user or the mypy devs are saying "use type: ignore as a workaround for now":
https://github.com/python/mypy/issues?q=is%3Aopen+label%3Afa...
Not to be shit-eating, but I never understood why people use python instead of Go other than for ML teams. I program mostly in Java and Go so would love a perspective.
I'm learning Python. Do someone knows a resource to learn the well-known tricks for "fast" Python? A book, a website, a cheat sheet or even a MOOC or part of a MOOC?
- Get the overall system structure in Python. Get the architectural design right, and the big-O stuff right.
- If there are bottlenecks, re-code those directly in C, cython, or similar. Or better yet, find libraries.
Python is great for expressing high-level operations and system design. It is also very easy to integrate with native code. I've never had much happiness in optimizing Python itself beyond that. Broadly speaking, code falls into three categories:
- Most code: Instant. Performance doesn't matter. Python
- Some code: Big-O(lifespan of the universe). Not worth building.
- Narrow slice of stuff in between: Don't do in Python, but use Python as the glue.
Not to be shit-eating, but I never understood why people use python instead of Go other than for ML teams. I program mostly in Java and Go so would love a perspective.
1. Most of what I am doing is calling other programs, often over ssh. The speed difference between the two is going to be tiny (where it is not, I use Golang)
2. Python is a more ergonomic language to work in a lot of the time. Wrapping a series of steps in a try block and then handling the errors in one go (very common in the things I am doing) is just easier to write, easier to maintain, and easier to read than what I have to do in Golang. And there are a ton of modules in Python that are just easier to work with than in Golang. And the resistance to the 'while... else' and 'for... else' patterns just saddens me. And the 'for' implementation in Golang often makes me want to tear my hair out... why make it hard to do this by reference?
3. Even in places where Golang should be much better, sometimes it is a challenge. For example when I am trying to parallelize something, but want to only have N number of workers going at a time. In Python I just use the worker pattern and I am done, I can even feed from one set of workers to another. In Golang I have to use a limited channel, and be careful that I block on that channel before I do anything that is going to eat a lot of memory (otherwise I have protected the CPU, but not memory resources). It feels like I am fighting the language there.
"Python is Slow, And That's Fine, Because It's Fast Enough" At least this is honest. No matter what the script does, no matter how fast the libraries, the Python intepreter has a slow startup time. On multiple occasions I have seen people commenting on HN argue that Python is not slow. I think for these commenters Python is "fast enough". For others, like me, it may not be "fast enough". IOW, the question is not whet…
> the Python intepreter has a slow startup time. This really depends on your perspective. Sure, it's a lot slower than running a native binary. But it's still fast enough for interactive tools that you run often. If you compare that to java tools, for example, which take seconds if not dozens of seconds to start (gradle, I'm looking at you!), python is far better.
Oh really?
https://www.mercurial-scm.org/wiki/OxidationPlan
> chg's very existence is because we need hg to be a native binary in order to avoid Python startup overhead. If hg weren't a Python script, we wouldn't need chg to be a separate program.