On 21 Mai, 20:20, Patrick Maupin <pmau...@gmail.com> wrote: > There are a lot of commercial programs written in Python. But any > company which thinks it has a lock on some kind of super secret sauce > isn't going to use Python, because it's very easy to reverse engineer > even compiled Python programs.
Decompiling Java or .NET bytecode isn't rocket science either. > Also, any company in a competitive > market where execution speed is extremely important might choose some > other language because, frankly, the fact that a development tool is > highly productive is not something that the end user directly cares > about. That only applies to CPU bound program code (most program code is I/O bound), and only to computational bottlenecks (usually less than 5% of the code) in the CPU bound programs. Today, most programs are I/O bound: You don't get a faster network connection or harddrive by using C. In this case, performance depends on other factors than choice of language. That is why Mercurial (written in Python) can be much faster than SVN (written in C). For computational bottlenecks we might want to try high-performance numerical libraries first. If that does not help, we can try to replace some Python with C. Python as "glue" does not mean Python is inferior to C. It just means it is a PITA to write C or Fortran all the time. I value my own time a lot more than a few extra CPU cycles. Who cares about speed where it is not needed? There are also a lot of uneducated FUD about the GIL: First, for I/O bound programs the GIL is not an issue, as threads that are blocked and waiting for I/O do not compete for the GIL. (That should be rather obvious, but my guesstimate is that most programmers do not understand this.) Second, for CPU bound programs the GIL is not an issue either: Fine-grained parallelization is done elsewhere than Python, e.g. hidden inside numerical libraries or implemented with OpenMP pragmas in C code. Course-grained parallelization can be done in Python using Python threads, as the GIL can be released in C using a couple of macros (or using ctypes.CDLL). In practice, the GIL rarely impairs anything, but create a lot of FUD form persons who do not understand the problem. -- http://mail.python.org/mailman/listinfo/python-list
