-1

What exactly is the sole purpose of python being an interpreter.

  1. It doesn't provide executable files (how a commercial software developer use it?)

  2. If any part of the code had bugs, it doesn't show up unless python goes to that line at run it. In large projects, all parts of code doesn't get interpreted every time, so, there would be a lot of hidden bugs inside project

  3. Every system should have a python installed in it to run those software's...

I am using py2exe, and I find myself puzzled to just look at the executable file size (too large).

user1027046
  • 293
  • 1
  • 6
  • 11
  • 3
    Run-time bugs in compiled languages have no difference for #2 – crashmstr Dec 05 '11 at 19:22
  • 4
    I'm wondering if this question should remain open. On one hand, this is a programming question with possible objective answers. On the other hand, it's not really constructive and probably will lead to a debate. – Bite code Dec 05 '11 at 19:31
  • 1
    @KevinSamuel: I agree this is not constructive, this is rather a subject for discussion, especially since the statements from the question are not fully true. – Tadeck Dec 05 '11 at 19:49

7 Answers7

12

First, answers to your questions.

  1. They can use it for parts of their system for which they don't mind the source being visible (e.g. extensions) or they can Open Source their application. They can also use it to develop backend services for something which they're providing as a service (e.g. Youtube). They can also use it for internal tools which they don't plan to release(e.g. with Google).

  2. That's why you need to write tests, exercise discipline and measure test coverage regularly. You sacrifice the compilers ability to check for things and some speed for advantages which I've detailed below.

  3. Yes but it's not too hard to bundle Python along with your app. The entire interpreter + libraries is not that big. Python is pretty much a standard on most UNIX environments today. This is usually not a practical problem. The same issue is there with (say) Java (you need the JVM installed).

py2exe bundles all the modules into a single executable. It will be big. If you want to do compiled programs that are lean, don't use Python. Wrong fit.

Now, a few reasons on why "interpreted".

  1. Faster development time. Programmer time is costlier than computer time so we should optimise for that.
  2. No compilation cycle. Very easy to make incremental changes and check. Quick turnaround.
  3. Introspection and dynamic typing allows certain kinds of coding not possible with some compiled languages like C.
  4. Cross platform. If you have an interpreter for your platform, the program will run there even if it was written on a different platform.
Noufal Ibrahim
  • 71,383
  • 13
  • 135
  • 169
  • 1
    +1 Python is generally good for prototyping (something that may fall to the 2nd reason you mentioned). But when it comes to " _programmer time is costlier than computer time_ ", then _it depends_ - depends on how many times the script is being executed (at some point computer time becomes costlier and then we may need to switch this specific script / module to C for example). – Tadeck Dec 05 '11 at 19:54
  • Agreed though I was speaking historically. Over the years, programmer time has become more costly than computer time. It's easy to get more hardware to throw at a problem. It's harder to find good people to sit and spend time to come up with a solution to a problem. – Noufal Ibrahim Dec 05 '11 at 19:55
  • Py2exe isn't developed anymore anyways. If you use cx_Freeze, your executable is much smaller (my whole program does 1mb). Looking into included modules, it seems to only be bringing in the needed ones. I don't know how this compares to py2exe, but I'm sure it's smaller. – John Doe Dec 05 '11 at 20:15
3

You bring up a few different issues, here are some responses:

1) Technically, Python isn't interpreted (usually) - it is compiled to bytecode and that bytecode is run on a virtual machine.

So Python doesn't provide executables because it runs bytecode, not machine code. You could just as well ask why Java doesn't produce executables. The standard advantages of virtual machines apply: A big one being a simplified cross-platform development experience.

You could distribute just the .pyc (compiled bytecode) files if you don't want your source to be available. See this reference.

2) Here, you are talking about dynamic vs. static languages. There are tradeoffs, of course. One disadvantage of dynamic languages, as you mention, is that you get more run-time errors rather than compile-time errors.

There are, of course, corresponding advantages. I'll point you to some resources discussing both sides:

3) Quite right. Just as you need the Java VM installed to run Java, perl to run Perl, etc.

Regarding your last point: The whole idea of running in a VM is that you can install that VM once, then run many different apps. By bundlig the whole VM with every app (such as with py2exe), you are going against that concept. So yes, you have to pay the cost in terms of size.

Community
  • 1
  • 1
jwd
  • 10,837
  • 3
  • 43
  • 67
1

Sole purpose of python is to provide a beautiful language to program in.

Your point #1 and #3 are similar and answer is that professional programmers use py2exe/pyinstaller etc to bundle their programs and distribute, in cases of frameworks/libraries they even don't need to do that.

Your point number #2 is also valid for statically compiled languages, something compiles correctly in C++ doesn't mean it will not crash at run-time or business logic is correct, you anyway need to test each part of your code, so with good unittests and functional tests python is at par with other languages in finding bugs, and as it doesn't need to be comiled and being dynamic means better productivity.

IMO

Anurag Uniyal
  • 85,954
  • 40
  • 175
  • 219
0

A python .exe has to necessarily include a complete copy of the python interpreter. As you say, since it's interpreted it won't touch every line of code until that line is actually run. Some parts may actually invoke a python parse/compile sequence (e.g. eval(), some regexes, etc...). These would fail in a compiled .exe unless the full interpreter was available.

mac
  • 42,153
  • 26
  • 121
  • 131
Marc B
  • 356,200
  • 43
  • 426
  • 500
0

Interactivity is good. I find it encourages making small, easily testable functions that build together to make an application.

Unless you are writing simple, statically linked applications, you will usually have some run-time baggage that must be included or installed (mfc, dot net, etc.) for compiled languages. Look at the winsxs folder. Sure, you get to "share" that stuff most of the time, but there is still a lot of space taken up by "needed", if hidden, requirements.

And as far as bugs, run-time bugs will be the same no matter what. Any good programmer would test as much as possible when making changes. This should catch what would be compile time bugs in other languages as well as testing run-time behavior.

crashmstr
  • 28,043
  • 9
  • 61
  • 79
  • 1
    Not sure about "Any compiled language usually has some run-time baggage that must be included or installed". The more compiled your application is, the less of this baggage it needs (e.g. statically compiled C code). The run-time baggage you're citing sounds more like libraries or JIT-compiler (for various forms of intermediate compiled language) – Bruno Dec 05 '11 at 19:34
  • run-time baggage == DLLs / .Net components / COM components, etc. Most real apps will have some of this. Often it is shared, but still it is there. Sure, if you just write a C app and only use the standard library... – crashmstr Dec 05 '11 at 19:38
  • (You can statically link a number of non-standard lib into a C app.) This is not really about compilation, but rather about expectations regarding the features available: language v.s. platform, e.g. Java as a language or Java as a runtime environment with all its API (there can even be non-Java languages on top of JRE, or using the Java language with various APIs: e.g. J2ME, J2SE, J2EE). What the expected baggage is really depends on the application and the general environment (OS, libraries, ...). – Bruno Dec 05 '11 at 19:46
  • The OP says "executable file size (too large)." That is what I was trying to address with the run-time size of a compiled app. i.e. the exe is *probably* not the *only* thing. In other words, the real space needed is often less visible. – crashmstr Dec 05 '11 at 19:48
0

Python is not an interpreter, but an interpreted language.

This question is more about interpreted language VS compiled languages which has actually no other answer that the usual "it depends of your need".

See Noufal Ibrahim for details, but I'm not sure this question is a good fit for SO.

Bite code
  • 578,959
  • 113
  • 301
  • 329
  • 1
    The OP wrote "python" not "Python" so he could have well intended the program `python`, which is an interpreter rather than a compiler. This doesn't change the essence of the debate, yet... since you remarked on that I thought it was fair to give the OP the benefit of doubt. :) – mac Dec 05 '11 at 19:41
0

(1) You can provide installers for Python code (which may install the Python environment). This doesn't prevent you from having commercial code. Note that you can also have Java (also "interpreted" or JIT-compiled) commercial or desktop code and require your users to install a JRE.

(2) Any language, even compiled and strongly type, may produce errors that only show up when you get to that given code (e.g. division by zero). I guess you may be referring to strongly v.s. loosely typed languages. It's not just a matter of compilation, but the fact that strongly-typed languages generally make it easier to find "structural" bugs (e.g. trying to use a string as a number) during the compilation process. In contrast, loosely-typed language often lead to shorter code, which may be easier to manage. What to use really depends on the goal of your application.

Bruno
  • 119,590
  • 31
  • 270
  • 376