On Sat, Feb 17, 2018 at 3:36 PM, Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote: > Python is really good for gluing together high-performance but user- and > programmer-hostile scientific libraries written in C and Fortran. You > wouldn't write a serious, industrial-strength neural network in pure > Python code and expect to process terabytes of data in any reasonable > time. > > But you might write a serious, industrial-strength neural network in C or > Rust, and then use your Python layer as the front-end to it, feeding data > in and out of the neural network from easy-to-write, easy-to-debug, easy- > to-maintain Python code.
Easy-to-debug. This deserves some expansion. One of the best aspects of Python is its debuggability (from readable code, lots of introspection, etc), so when you convert low level functionality into C, you ideally want to start with the parts that can be most easily unit-tested. User interfaces are notoriously hard to unit test, but pure functions can be more thoroughly tested. So you translate the pure functions first. There's often a strong correlation between the easily-testable functions and the performance bottlenecks. I'm hand-waving away a ton of details and complexities here, and it's certainly not a hard-and-fast rule, but it's a very common correlation. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
