On 05/06/14 10:14, Alain Ketterlin wrote:

> Type safety.

Perhaps. Python has strong type safety. It is easier to spoof a type in C or C++ than Python.

Python 3 also has type annotations that can be used to ensure the types are correct when we run tests. In a world of consenting adults I am not sure we really need static types compared to ducktyping.

>(And with it comes better performance ---read battery
> life--- and better static analysis tools, etc.)

Perhaps, perhaps not. My experience is that only a small percentage of the CPU time is spent in the Python interpreter.

- The GPU does not care if my OpenGL shaders are submitted from Python or C. Nor do any other library or framework. If I use OpenCV to capture live video, it could not care less if I use Python or C. A cocoa app using PyObjC will not use Python to prepare each pixel on the screen. Even if the screen is frequently updated, the battery is spent somewhere else than in the Python interpreter.

- A GUI program that is mostly idle spends more battery on lighting the screen than executing code.

- If I use a 3g connection on my iPad, most of the battery will be spent transmitting and receiving data on the mobile network.

- Where is the battery spent if I stream live video? In the Python interpreter that executes a few LOC for each frame? I will make the bold statement that an equivalent C program would exhaust the battery equally fast.

- If an web app seems slow, it is hardly every due to Python on the server side.

- If the response time in a GUI is below the limits of human perception, can the user tell my Python program is slower than a C program?

For the rare case where I actually have to run algorithmic code in Python, there is always Numba (an LLVM-based JIT compiler) or Cython which can be used to speed things up to C performance when the Python prototype works. I rarely need to do this, though.

> LLVM (an Apple-managed
> project) for the middle- and back-end, and a brand new front-end
> incorporating a decent type system (including optional types for
> instance).

Numba uses LLVM.

When I compile Cython modules I use LLVM on this computer.

> Swift's memory management is similar to python's (ref. counting). Which
> makes me think that a subset of python with the same type safety would
> be an instant success.

A Python with static typing would effectively be Cython :)

It is the tool of choice in many scientific Python projects today. Most projects affiliated with NumPy and SciPy prefer Cython to C or Fortran for new code.



Reply via email to