By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
439,944 Members | 1,819 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 439,944 IT Pros & Developers. It's quick & easy.

Python compiled?

P: n/a
Hi all. I'm sorry for a noob question like this but I'll try to ask it
anyway.
One of the greatest problem that may discourage a new user to choose Python
language is it's interpreted nature.
Another important problem is that no interpreter is installed on Windows
machine by default and this makes harder to distribute the software.
Does it is planned that, in a far future, Python will implement a form of
compilation?
This would be awesome.
Sep 5 '05 #1
Share this Question
Share on Google+
26 Replies


P: n/a
billiejoex wrote:
Hi all. I'm sorry for a noob question like this but I'll try to ask it
anyway.
One of the greatest problem that may discourage a new user to choose Python
language is it's interpreted nature.
What? The instant gratification of immediate results is not
discouraging.
Another important problem is that no interpreter is installed on Windows
machine by default and this makes harder to distribute the software.
Python isn't that big to install, and people don't have problems with
small downloads
Does it is planned that, in a far future, Python will implement a form of
compilation?
This would be awesome.


Again, I don't see how compiling would make Python better.

Sep 5 '05 #2

P: n/a
> One of the greatest problem that may discourage a new user to choose Python
language is it's interpreted nature.
Strange.. this is one reason I love Python :-)
Another important problem is that no interpreter is installed on Windows
machine by default and this makes harder to distribute the software.
Does it is planned that, in a far future, Python will implement a form of
compilation?
This would be awesome.


py2exe (http://starship.python.net/crew/theller/py2exe/) and pyinstaller
(http://pyinstaller.hpcf.upr.edu/pyinstaller/) compile python programs
into .exe files that can be executed on any Win32 machine.

So you can develop the code using the python interpreter and deploy it
using either of these. I have used py2exe and nsis installer to create
setup versions of my applications and it deployment is really smooth,
just like any compiled software.

-Kartic
Sep 5 '05 #3

P: n/a
Hi !
One of the greatest reason which encouraged me to choose Python is its
interpreted nature (more exactly its nature of dynamic language).

The utilities of distribution, or packaging, are enough numerous to solve
this kind of problem.

The existence of Py2exe (inter alia), could concillier the needs...
@-salutations

Michel Claveau

Sep 5 '05 #4

P: n/a
there are "noob" questions and there are uneducated questions, yours
are of the latter ( actually yours are STATEMENTS not questions ), and
just trolling for what it is worth, if you would take the time to read
what Python is and why it is you would not be asking these "questions".

Sep 5 '05 #5

P: n/a
I'm sorry. Maybe you misunderstanded.
I know the great advanteges deriving by using interpretation too, I
appreciate it very much (I'm newbie in Python and the interpeter really
helps me out in many situations), but a 'pure' interpretated language needs
obligatorily an interpreter and (sorry for repeating) this could be a
problem for distribution (imho).
Py2exe is surely a good compromise but it is not comparable to an executable
file compiled, for example, in C for obvious sizing reasons (I never used
PyInstaller. I surely try it out as soon as possible, but I didn't think
that the output package size is too much different than py2exe one).
For these reasons I think that an hibrid language that permits
interpretation and compilation at the same time, should be a great
advantage.

best regards
Sep 5 '05 #6

P: n/a
> there are "noob" questions and there are uneducated questions, yours
are of the latter ( actually yours are STATEMENTS not questions ), and
just trolling for what it is worth, if you would take the time to read
what Python is and why it is you would not be asking these "questions".


I'm really sorry man. I didn't wanted to be uneducated, believe me.
I wrote fastly, I'm new in Python and probably for my language problems I
didn't expressed concepts properly.

Sep 5 '05 #7

P: n/a
billiejoex wrote:
I'm sorry. Maybe you misunderstanded.
I know the great advanteges deriving by using interpretation too, I
appreciate it very much (I'm newbie in Python and the interpeter really
helps me out in many situations), but a 'pure' interpretated language needs
obligatorily an interpreter and (sorry for repeating) this could be a
problem for distribution (imho).


Do youself a favour - google this group for that question. You'll get
plenty of answers to your questions and allegations. This dead Horse has
been beaten to hell and back. Really.

Diez
Sep 5 '05 #8

P: n/a
billiejoex <bi********@fastwebnet.it> wrote:
interpretation and compilation at the same time, should be a great
advantage.


Python is compiled and needs a runtime environment.
just like java does and like C needs the C standard library installed.

I can see no differences except one is compiled to native code, the
other is compiled to bytecode and JITted or interpreted and python is
compiled to bytecode and interpreted or (with psyco) JITted.

--
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.4
Blog: http://vvolonghi.blogspot.com
http://weever.berlios.de
Sep 5 '05 #9

P: n/a
"billiejoex" wrote:
I know the great advanteges deriving by using interpretation too, I appreciate it very much (I'm newbie in Python and the
interpeter really helps me out in many situations), but a 'pure' interpretated language needs obligatorily an interpreter and
(sorry for repeating) this could be a problem for distribution (imho).


Python is a compiled language; the Python source code you write is
compiled to byte codes, which are executed by a virtual machine.

on windows, that virtual machine consists of a DLL. distributing DLLs
have been a solved problem for at least 15-20 years...

</F>

Sep 5 '05 #10

P: n/a
On 2005-09-05, billiejoex <bi********@fastwebnet.it> wrote:
Py2exe is surely a good compromise but it is not comparable to
an executable file compiled, for example, in C for obvious
sizing reasons
In theory something written in C could be smaller. In
practice, it isn't. Most "real" apps end up shipping with a
directory full of .dlls, help-files, uninstall scripts and
miscellaneous other stuff. There are very, very few pure "exe"
single-file executable windows apps. Putty is the only one
I've run across in a _long_ while. Everything else ends up
installing a directory full of libraries and help files and
whatnot. In practice, a Python app packages with py2exe and
Inno Setup behaves exactly the same as anything other recent
Windows app.
(I never used PyInstaller. I surely try it out as soon as
possible, but I didn't think that the output package size is
too much different than py2exe one). For these reasons I think
that an hibrid language that permits interpretation and
compilation at the same time, should be a great advantage.


You're wrong. The size of a packaged Python app is simply not
a concern. I've distributed several Python wxWidgets apps
after packaging them with py2exe and Inno setup. I never got a
single comment about the size of the packaged app -- all I got
were surprised remarks about how they thought I was a Unix guy
who didn't know anything about Windows. I reply that I am, and
I don't.

--
Grant Edwards grante Yow! Put FIVE DOZEN red
at GIRDLES in each CIRCULAR
visi.com OPENING!!
Sep 6 '05 #11

P: n/a
On 2005-09-05, Fredrik Lundh <fr*****@pythonware.com> wrote:
distributing DLLs have been a solved problem for at least
15-20 years...


There are days when some poeple might disagree with that. ;)

--
Grant Edwards grante Yow! LOOK!!! I'm WALKING
at in my SLEEP again!!
visi.com
Sep 6 '05 #12

P: n/a
Grant Edwards wrote:
distributing DLLs have been a solved problem for at least
15-20 years...


There are days when some poeple might disagree with that. ;)


distributing them has never been a problem. installing them in a
shared location has always been a problem.

(the solution to the latter is simple, of course: don't do that)

</F>

Sep 6 '05 #13

P: n/a
Clear. Thank you all.
Sep 6 '05 #14

P: n/a
On 2005-09-06, Fredrik Lundh <fr*****@pythonware.com> wrote:
Grant Edwards wrote:
> distributing DLLs have been a solved problem for at least
> 15-20 years...


There are days when some poeple might disagree with that. ;)


distributing them has never been a problem. installing them in a
shared location has always been a problem.

(the solution to the latter is simple, of course: don't do that)

</F>


I should add that py2exe doesn't do that, so py2exe'd apps tend
to be better behaved than many other sorts of Window's apps.

--
Grant Edwards grante Yow! ALFRED JARRY! Say
at something about th' DEATH
visi.com of DISCO!!
Sep 6 '05 #15

P: n/a
On Mon, 5 Sep 2005 22:48:19 +0200, billiejoex <bi********@fastwebnet.it> wrote:
there are "noob" questions and there are uneducated questions, yours
are of the latter ( actually yours are STATEMENTS not questions ), and
just trolling for what it is worth, if you would take the time to read
what Python is and why it is you would not be asking these "questions".


I'm really sorry man. I didn't wanted to be uneducated, believe me.
I wrote fastly, I'm new in Python and probably for my language problems I
didn't expressed concepts properly.


I didn't think they were uneducated, they were good questions.
At least if one understands that the problem is that the /end user/
percieves a problem.

I hope people are less hesitant to install "interpreted" applications today
than they were ten years ago.

I also believe it's better to convince the end user to install Python before
installing the application[1], rather than to try to sneak in an interpreter
with py2exe or something -- an interpreter which the end user cannot update,
manage or use for other things.

/Jorgen

[1] Might be hard to convince people who have ever installed a Java
interpreter -- when I do that on Windows, I usually break at least one
existing Java application, and I usually get a whole lot of useless
desktop icons, a funny thing in the system tray, etc.

--
// Jorgen Grahn <jgrahn@ Ph'nglui mglw'nafh Cthulhu
\X/ algonet.se> R'lyeh wgah'nagl fhtagn!
Sep 6 '05 #16

P: n/a
On 2005-09-06, Jorgen Grahn <jg*********@algonet.se> wrote:
I also believe it's better to convince the end user to install Python before
installing the application[1], rather than to try to sneak in an interpreter
with py2exe or something -- an interpreter which the end user cannot update,
manage or use for other things.


There's a typo in that last phrase. It should read "[...] --
an interpreter the user isn't going to uninstall or break
because he doesn't know what it is or why it's there."

--
Grant Edwards grante Yow! ... I don't like
at FRANK SINATRA or his
visi.com CHILDREN.
Sep 6 '05 #17

P: n/a
On Tue, 06 Sep 2005 03:06:52 -0000, rumours say that Grant Edwards
<gr****@visi.com> might have written:
There are very, very few pure "exe"
single-file executable windows apps. Putty is the only one
I've run across in a _long_ while.


Then you should also run across Media Player Classic (download it from
http://sourceforge.net/projects/guliverkli ). Just a plain exe, no
installation needed, and is an excellent media player. For a funny
side, check the program's version history.
--
TZOTZIOY, I speak England very best.
"Dear Paul,
please stop spamming us."
The Corinthians
Sep 6 '05 #18

P: n/a
On Tuesday 06 September 2005 11:32 am, Jorgen Grahn wrote:
I hope people are less hesitant to install "interpreted" applications today
than they were ten years ago.

I also believe it's better to convince the end user to install Python before
installing the application[1], rather than to try to sneak in an interpreter
with py2exe or something -- an interpreter which the end user cannot update,
manage or use for other things.


I have to confess to be very ignorant about the Windows installation options
for Python packages, but surely in principle at least, it should be possible
to make self-installing .EXE files that do what I get from

apt-get install python-mypackage

or at least

dpkg --install mypackage

That is to say, which install an interpreter if one isn't already there, and
then install the package. Or, upon finding an interpreter install into it
along the lines of distutils.

I mean, with the whole AUTOEXEC.BAT start up a CD and run whatever
evil code we find there as soon as we stick it into our unwisely
promiscuous machine, it ought to make it possible for the installation
to be completely transparent to the user.

You know, after writing that, I'm starting to rethink what people
mean when they say Windows is "easy". ;-)

Cheers,
Terry

--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks http://www.anansispaceworks.com

Sep 7 '05 #19

P: n/a
On Tue, 06 Sep 2005 17:29:46 -0000, Grant Edwards <gr****@visi.com> wrote:
On 2005-09-06, Jorgen Grahn <jg*********@algonet.se> wrote:
I also believe it's better to convince the end user to install Python before
installing the application[1], rather than to try to sneak in an interpreter
with py2exe or something -- an interpreter which the end user cannot update,
manage or use for other things.


There's a typo in that last phrase. It should read "[...] --
an interpreter the user isn't going to uninstall or break
because he doesn't know what it is or why it's there."


I meant what I wrote, of course (and you should really have added a smiley.)

Might be because I'm more at home in Linux (Debian). The
bundling-an-interpreter approach to distribution software is simply not
applicable on those platforms, for many different reasons.

Maybe that's why I have a hard time even understanding the idea.
I see lots of problems and few benefits.

For example, the issue of security fixes. If there's a bug in Python which
makes anyone running an interpreter vulnerable, how are those users even
going to /find out/ about it?

/Jorgen

--
// Jorgen Grahn <jgrahn@ Ph'nglui mglw'nafh Cthulhu
\X/ algonet.se> R'lyeh wgah'nagl fhtagn!
Sep 8 '05 #20

P: n/a
On Wed, 7 Sep 2005 08:40:28 -0500, Terry Hancock <ha*****@anansispaceworks.com> wrote:
On Tuesday 06 September 2005 11:32 am, Jorgen Grahn wrote:
I hope people are less hesitant to install "interpreted" applications today
than they were ten years ago.

I also believe it's better to convince the end user to install Python before
installing the application[1], rather than to try to sneak in an interpreter
with py2exe or something -- an interpreter which the end user cannot update,
manage or use for other things.


I have to confess to be very ignorant about the Windows installation options
for Python packages, but surely in principle at least, it should be possible
to make self-installing .EXE files that do what I get from

apt-get install python-mypackage

or at least

dpkg --install mypackage

That is to say, which install an interpreter if one isn't already there, and
then install the package. Or, upon finding an interpreter install into it
along the lines of distutils.


It has been a while since I used bdist_wininst, but I hope it at least

a) detects if there is a suitable Python installed
b) otherwise, suggests that the user should install one,
explains why, gives the URL of a suitable package,
and the size of the download

Things get trickier, of course, if the software depends on external packages
and modules.

/Jorgen

--
// Jorgen Grahn <jgrahn@ Ph'nglui mglw'nafh Cthulhu
\X/ algonet.se> R'lyeh wgah'nagl fhtagn!
Sep 8 '05 #21

P: n/a
On 2005-09-08, Jorgen Grahn <jg*********@algonet.se> wrote:
On Tue, 06 Sep 2005 17:29:46 -0000, Grant Edwards <gr****@visi.com> wrote:
On 2005-09-06, Jorgen Grahn <jg*********@algonet.se> wrote:
I also believe it's better to convince the end user to install
Python before installing the application[1], rather than to
try to sneak in an interpreter with py2exe or something -- an
interpreter which the end user cannot update, manage or use
for other things.
There's a typo in that last phrase. It should read "[...] --
an interpreter the user isn't going to uninstall or break
because he doesn't know what it is or why it's there."


I meant what I wrote, of course (and you should really have
added a smiley.)


Nah, I knew everybody would get it without one. c.l.p readers
are smarter than the average bear.
Might be because I'm more at home in Linux (Debian). The
bundling-an-interpreter approach to distribution software is
simply not applicable on those platforms, for many different
reasons.
Of course. I never ship an interpreter for Linux apps. Just
the python source. I thought we were talking about Windows
apps what with the reference to py2exe and Inno Setup and
whatnot. Linux comes with Python already installed, though
sometimes wxPyton and friends aren't installed by default.
Mostly my Linux Python apps are strictly command-line anyway.
Maybe that's why I have a hard time even understanding the
idea. I see lots of problems and few benefits.
I've had limited success telling Windows users to install
Python. Even if you point them to the ActiveState MSI file
with all the Win32 stuff already bundled, they seem to muck it
up most of the time. I can't imagine how -- it's dead simple
to install, but they manage to screw it up.
For example, the issue of security fixes. If there's a bug in
Python which makes anyone running an interpreter vulnerable,
how are those users even going to /find out/ about it?


I guess you ship them an update -- same as you would for a
security fix for the other parts of the application.

--
Grant Edwards grante Yow! My TOYOTA is built
at like a... BAGEL with CREAM
visi.com CHEESE!!
Sep 9 '05 #22

P: n/a
"billiejoex" <bi********@fastwebnet.it> wrote:

Hi all. I'm sorry for a noob question like this but I'll try to ask it
anyway.
One of the greatest problem that may discourage a new user to choose Python
language is it's interpreted nature.


I doubt it. C#, VB.NET, VBscript, Javascript and Perl have not suffered
from being interpreted.
--
- Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.
Sep 10 '05 #23

P: n/a
Tim Roberts <ti**@probo.com> writes:
I doubt it. C#, VB.NET, VBscript, Javascript and Perl have not suffered
from being interpreted.


Are you kidding?
Sep 10 '05 #24

P: n/a

"Tim Roberts" <ti**@probo.com> wrote in message
news:90********************************@4ax.com...
"billiejoex" <bi********@fastwebnet.it> wrote:

Hi all. I'm sorry for a noob question like this but I'll try to ask it
anyway.
One of the greatest problem that may discourage a new user to choose
Python
language is it's interpreted nature.


I doubt it. C#, VB.NET, VBscript, Javascript and Perl have not suffered
from being interpreted.


Nor has 386 'machine language' suffered from being interpreted, at a deeper
level, by microcode.

tjr

Sep 10 '05 #25

P: n/a
Terry Reedy wrote:
"Tim Roberts" <ti**@probo.com> wrote in message
news:90********************************@4ax.com...
"billiejoex" <bi********@fastwebnet.it> wrote:
Hi all. I'm sorry for a noob question like this but I'll try to ask it
anyway.
One of the greatest problem that may discourage a new user to choose
Python
language is it's interpreted nature.


I doubt it. C#, VB.NET, VBscript, Javascript and Perl have not suffered
from being interpreted.


Nor has 386 'machine language' suffered from being interpreted, at a deeper
level, by microcode.


I think both you and Paul may be missing Tim's point. I don't think he's
talking about "suffering" in technical respects, like speed. He's
talking about popularity.

--
Robert Kern
rk***@ucsd.edu

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

Sep 10 '05 #26

P: n/a

"Robert Kern" <rk***@ucsd.edu> wrote in message
news:df**********@sea.gmane.org...
Terry Reedy wrote:
Nor has 386 'machine language' suffered from being interpreted, at a
deeper
level, by microcode.


I think both you and Paul may be missing Tim's point. I don't think he's
talking about "suffering" in technical respects, like speed. He's
talking about popularity.


I knew that ;-) and meant that ;;--)).

Of course, many people don't know that 'machine code' is often now
interpreted -- nor that Python code is compiled to something by all current
implementations. Perhaps we should call the CPython 'interpreter' the
CPython interpreter-compiler that it is.

Terry J. Reedy


Sep 11 '05 #27

This discussion thread is closed

Replies have been disabled for this discussion.