Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Why not a Python compiler?

8 views
Skip to first unread message

Santiago Romero

unread,
Feb 5, 2008, 3:19:34 AM2/5/08
to

( Surely if this question has been asked for a zillion of times... )
( and sorry for my english! )

I'm impressed with python. I'm very happy with the language and I
find Python+Pygame a very powerful and productive way of writing 2D
games. I'm not, at this moment, worried about execution speed of the
small game I'm working on (it runs at full 60 fps even in an old AMD-
K6 450 Laptop computer), but I continue asking me the same question:

Why not a Python COMPILER?

It would be very nice to be able to output Linux, MAC or Windows
binaries of compiled (not bytecompiled) code. It would run faster, it
will be smaller in size (I think) and it will be easy to distribute to
people not having python installed. Yes, I know about py2exe, but I'm
not sure if that's the right aproach.

So, what's wrong with compiling python?

Maybe is not possible due to nature of the language? Is just a
decision?

What do you think about this?

cokof...@gmail.com

unread,
Feb 5, 2008, 3:30:18 AM2/5/08
to

I don't know the exact details but I think the issue is the dynamic
nature of Python makes it impossible to correctly store the various
types and changes into compiled code. Someone else will probably be
able to provide a good reason as to why it isn't very feasible, nor a
good idea. If you want to speed up your python look at Psyco.
http://psyco.sourceforge.net/

Jeroen Ruigrok van der Werven

unread,
Feb 5, 2008, 3:33:45 AM2/5/08
to Santiago Romero, pytho...@python.org
-On [20080205 09:22], Santiago Romero (sro...@gmail.com) wrote:
> Why not a Python COMPILER?

A lot of things within Python are very run-time dependent so creating a
compiler is not trivial work.

There are, however, endeavours underway like shed skin:

http://code.google.com/p/shedskin/

This provides a Python to C++ compiler, but it enforces some restrictions on
Python's code.

--
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/
We have met the enemy and they are ours...

Kay Schluehr

unread,
Feb 5, 2008, 3:37:18 AM2/5/08
to
On Feb 5, 9:19 am, Santiago Romero <srom...@gmail.com> wrote:
> ( Surely if this question has been asked for a zillion of times... )

Sure. You can access comp.lang.python via google.google.com. It has a
search function.

Dustan

unread,
Feb 5, 2008, 7:07:21 AM2/5/08
to
On Feb 5, 2:37 am, Kay Schluehr <kay.schlu...@gmx.net> wrote:
> On Feb 5, 9:19 am, Santiago Romero <srom...@gmail.com> wrote:
>
> > ( Surely if this question has been asked for a zillion of times... )
>
> Sure. You can access comp.lang.python via

groups

> .google.com.

Bruno Desthuilliers

unread,
Feb 5, 2008, 7:13:48 AM2/5/08
to
Santiago Romero a écrit :

> ( Surely if this question has been asked for a zillion of times... )

Why not checking this by yourself ? google is down ?-)

> I'm impressed with python. I'm very happy with the language and I
> find Python+Pygame a very powerful and productive way of writing 2D
> games. I'm not, at this moment, worried about execution speed of the
> small game I'm working on (it runs at full 60 fps even in an old AMD-
> K6 450 Laptop computer), but I continue asking me the same question:
>
> Why not a Python COMPILER?

http://docs.python.org/lib/module-compiler.html

> It would be very nice to be able to output Linux, MAC or Windows
> binaries of compiled (not bytecompiled) code.

Ah, sorry.

> It would run faster, it
> will be smaller in size (I think)

These two points are very questionnable given Python's dynamicity. IIRC,
some guru already made the point, a couple or more years ago, that it
would be a lot of effort and buy *very* few wrt/ execution speed since
everything still have to happens at runtime. IOW, a JIT compiler seems a
far better solution, but this (so far) still impose some (serious)
limitations to be of any help.

Ript...@gmail.com

unread,
Feb 5, 2008, 10:53:13 AM2/5/08
to

> Why not a Python COMPILER?

What about a Python JIT hardware chip, so the CPU doesn't have to
translate. Although it seems to me that with today's dual and quad
core processors that this might be a mute point because you could just
use one of the cores.

Steve Holden

unread,
Feb 5, 2008, 11:44:55 AM2/5/08
to pytho...@python.org
What about a chip that reads your mind and does what you want it to?

I am sure that would be popular with all the frustrated computer users
there are in the world.

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/

Jeff Schwab

unread,
Feb 5, 2008, 11:54:48 AM2/5/08
to Steve Holden, pytho...@python.org
Steve Holden wrote:
> Ript...@gmail.com wrote:
>>> Why not a Python COMPILER?
>>
>> What about a Python JIT hardware chip, so the CPU doesn't have to
>> translate. Although it seems to me that with today's dual and quad
>> core processors that this might be a mute point because you could just
>> use one of the cores.
>>
> What about a chip that reads your mind and does what you want it to?

+1!

> I am sure that would be popular with all the frustrated computer users
> there are in the world.

I'll take two. (Chips, not frustrated users).

--
"I sold the cow for these magic ICs," said Jack.

Jeff Schwab

unread,
Feb 5, 2008, 11:54:48 AM2/5/08
to Steve Holden, pytho...@python.org
Steve Holden wrote:
> Ript...@gmail.com wrote:
>>> Why not a Python COMPILER?
>>
>> What about a Python JIT hardware chip, so the CPU doesn't have to
>> translate. Although it seems to me that with today's dual and quad
>> core processors that this might be a mute point because you could just
>> use one of the cores.
>>
> What about a chip that reads your mind and does what you want it to?

+1!

> I am sure that would be popular with all the frustrated computer users
> there are in the world.

I'll take two. (Chips, not frustrated users).

Jeff

unread,
Feb 5, 2008, 1:20:20 PM2/5/08
to
I'm surprised no one has mentioned Pyrex. It can be used to write
stand-alone C programs using near-Python syntax:

Pyrex: http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/
Stand-alone how-to: http://www.freenet.org.nz/python/embeddingpyrex/
Pyrex how-to: http://ldots.org/pyrex-guide/,
http://www.artfulcode.net/articles/extending-python-pyrex/ (shameless
plug, I know)

Ript...@gmail.com

unread,
Feb 5, 2008, 4:22:13 PM2/5/08
to
On Feb 5, 11:44 am, Steve Holden <st...@holdenweb.com> wrote:

I'm not sure where that came from. Microsoft had talked about a
hardware JIT for .NET a few years back. I was just wondering if anyone
had thought of it for python or anything like that.

Steven D'Aprano

unread,
Feb 5, 2008, 4:54:02 PM2/5/08
to


Okay, you know how hard it is to create a software JIT compiler for a
language as dynamic as Python? It's REALLY HARD, which is why it hasn't
already been done[1]. Now you want that done in *hardware*, which is much
harder. Who's going to spend the money on R&D?

I'm sure there are thousands of l33t hax0rs out there who have thought
"Wouldn't it be c00l if there was a chip I could put into my PC to make
Python run a million times faster!!!". When I was younger and more
stupi^W innocent I had a mad fegairy for Forth and Lisp chips, but their
lack of financial viability and their unfortunate habit of actually being
*slower* than running the language in software put a big dent in the
idea. As general purpose CPUs got faster, the idea of making a specialist
language chip is now pretty much dead. Even if you could find a niche
market prepared to pay for it, "people who run Python programs" is
probably not that market.


[1] Apart from some specializing compilers like Pysco
http://psyco.sourceforge.net/introduction.html


--
Steven

Steve Holden

unread,
Feb 5, 2008, 5:07:40 PM2/5/08
to pytho...@python.org
Quite.

joseph...@gmail.com

unread,
Feb 5, 2008, 5:55:20 PM2/5/08
to
On Feb 5, 4:54 pm, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com.au> wrote:

> Okay, you know how hard it is to create a software JIT compiler for a
> language as dynamic as Python? It's REALLY HARD, which is why it hasn't
> already been done[1]. Now you want that done in *hardware*, which is much
> harder. Who's going to spend the money on R&D?
>

To be clear, compiling a language that is dynamic *in the particular
way Python is designed to be dynamic*, for example, documenting and
exporting as an API the dictionary lookup mechanism for method
dispatch, is really hard.

Compiling languages such as Lisp, which are quite dynamic, and in some
ways much *more* dynamic than Python, to native machine code has been
standard practice since the 1970s.

The issue is how Python, for whatever reason, was designed as a
language. Not with whether it is dynamic or static.

Luis M. González

unread,
Feb 5, 2008, 6:43:37 PM2/5/08
to


There are some projects aimed to speed up Python by a large margin.
Right now you can use psyco, which is considered to be feature
complete, and whose future relies on the Pypy project.

Pypy is a very ambitious project and it aims, amongst many other
goals, to provide a fast just-in-time python implementation.
They even say that the "secret goal is being faster than c, which is
nonsense, isn´t it?" (I still didn´t get the joke though...).

And finally, you have ShedSkin, a project developed by one lonely and
heroic coder (Mark Dufour).
Shedskin aims at being a static python compiler, which can translate a
subset of python to stand alone executables.
It also can compile extension modules for cpython.
It works by translating python to c++ and then to machine code.
The python code must be done in a static way (getting rid of dynamic
features like, for example, not asigning different types to the same
variable).

Luis

John Nagle

unread,
Feb 6, 2008, 12:05:10 AM2/6/08
to

Exactly. Or "when the only tool you have is a hash, everything
looks like a dictionary". The performance problems of Python stem
from the difficulty of telling whether a hash lookup is really necessary.
The killer is that Python lets you modify the namespaces of all functions,
objects, and modules from the outside. Given that language spec,
you're stuck with an implementation like CPython where everything really
is a hash internally.

If the namespaces of objects, functions, and modules could only be
modified from within the object, function, or module, then a compiler
could examine the module and see if there was anything that required
the general late-binding case. Everything else could then be bound early,
avoiding huge numbers of unnecessary lookups and yielding a considerable
speedup. It's necessary to provide for the late-binding case to keep
the dynamism of the language, but late-binding everything kills
performance.

Shed Skin has restrictions like that, but Shed Skin is being
developed by one guy, which isn't much for an optimizing compiler.

John Nagle

Reedick, Andrew

unread,
Feb 6, 2008, 10:04:51 AM2/6/08
to Luis M. González, pytho...@python.org

> -----Original Message-----
> From: python-list-bounces+jr9445=att...@python.org [mailto:python-
> list-bounces+jr9445=att...@python.org] On Behalf Of Luis M. González
> Sent: Tuesday, February 05, 2008 6:44 PM
> To: pytho...@python.org
> Subject: Re: Why not a Python compiler?
>
>
> Pypy is a very ambitious project and it aims, amongst many other
> goals, to provide a fast just-in-time python implementation.
> They even say that the "secret goal is being faster than c, which is
> nonsense, isn´t it?" (I still didn´t get the joke though...).
>

'c' is also the speed of light. And since nothing can travel faster than light...

One demerit has been marked against your geek card for missing an obvious science pun. Additionally, your membership to the Star Trek Lifestyle Adventure Club has been put on probationary status for the next twelve parsecs.

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621


Grant Edwards

unread,
Feb 6, 2008, 10:35:09 AM2/6/08
to
On 2008-02-06, Reedick, Andrew <jr9...@ATT.COM> wrote:

>> Pypy is a very ambitious project and it aims, amongst many
>> other goals, to provide a fast just-in-time python
>> implementation. They even say that the "secret goal is being
>> faster than c, which is nonsense, isn´t it?" (I still didn´t
>> get the joke though...).
>
> 'c' is also the speed of light.

'c' is the speed of light _in_a_vacuum_.

> And since nothing can travel faster than light...

Nothing can travel faster than the speed of light
_in_a_vacuum_. There are situtaitons where things can (and
regularly do) travel faster than light:
http://en.wikipedia.org/wiki/Cherenkov_radiation

Half a demerit.

> One demerit has been marked against your geek card for missing
> an obvious science pun. Additionally, your membership to the
> Star Trek Lifestyle Adventure Club has been put on
> probationary status for the next twelve parsecs.

Ouch. Two demerits for using the distance unit "parsec" in a
context where a quantity of time was required.

--
Grant Edwards grante Yow! Boys, you have ALL
at been selected to LEAVE th'
visi.com PLANET in 15 minutes!!

Reedick, Andrew

unread,
Feb 6, 2008, 11:14:10 AM2/6/08
to Grant Edwards, pytho...@python.org
> -----Original Message-----
> From: python-list-bounces+jr9445=att...@python.org [mailto:python-
> list-bounces+jr9445=att...@python.org] On Behalf Of Grant Edwards
> Sent: Wednesday, February 06, 2008 10:35 AM
> To: pytho...@python.org
> Subject: Re: Why not a Python compiler?
>
> On 2008-02-06, Reedick, Andrew <jr9...@ATT.COM> wrote:
>
> >> Pypy is a very ambitious project and it aims, amongst many
> >> other goals, to provide a fast just-in-time python
> >> implementation. They even say that the "secret goal is being
> >> faster than c, which is nonsense, isn´t it?" (I still didn´t
> >> get the joke though...).
> >
> > 'c' is also the speed of light.
>
> 'c' is the speed of light _in_a_vacuum_.

True.


> > And since nothing can travel faster than light...
>
> Nothing can travel faster than the speed of light
> _in_a_vacuum_. There are situtaitons where things can (and
> regularly do) travel faster than light:
> http://en.wikipedia.org/wiki/Cherenkov_radiation


Nope. It propagates, not travels, faster than light. Go ask a physicist to explain it. It's odd...


>
> > One demerit has been marked against your geek card for missing
> > an obvious science pun. Additionally, your membership to the
> > Star Trek Lifestyle Adventure Club has been put on
> > probationary status for the next twelve parsecs.
>
> Ouch. Two demerits for using the distance unit "parsec" in a
> context where a quantity of time was required.


Ten demerits for not catching the Star Wars Kessel Run reference.


Steve Holden

unread,
Feb 6, 2008, 11:51:04 AM2/6/08
to Reedick, Andrew, Grant Edwards, pytho...@python.org
Reedick, Andrew wrote:
>> -----Original Message-----
>> From: python-list-bounces+jr9445=att...@python.org [mailto:python-
>> list-bounces+jr9445=att...@python.org] On Behalf Of Grant Edwards
>> Sent: Wednesday, February 06, 2008 10:35 AM
>> To: pytho...@python.org
>> Subject: Re: Why not a Python compiler?
>>
>> On 2008-02-06, Reedick, Andrew <jr9...@ATT.COM> wrote:
>>
>>>> Pypy is a very ambitious project and it aims, amongst many
>>>> other goals, to provide a fast just-in-time python
>>>> implementation. They even say that the "secret goal is being
>>>> faster than c, which is nonsense, isn´t it?" (I still didn´t
>>>> get the joke though...).
>>> 'c' is also the speed of light.
>> 'c' is the speed of light _in_a_vacuum_.
>
> True.

>
>
>>> And since nothing can travel faster than light...
>> Nothing can travel faster than the speed of light
>> _in_a_vacuum_. There are situtaitons where things can (and
>> regularly do) travel faster than light:
>> http://en.wikipedia.org/wiki/Cherenkov_radiation
>
>
> Nope. It propagates, not travels, faster than light. Go ask a physicist to explain it. It's odd...
>
>
>>> One demerit has been marked against your geek card for missing
>>> an obvious science pun. Additionally, your membership to the
>>> Star Trek Lifestyle Adventure Club has been put on
>>> probationary status for the next twelve parsecs.
>> Ouch. Two demerits for using the distance unit "parsec" in a
>> context where a quantity of time was required.
>
>
> Ten demerits for not catching the Star Wars Kessel Run reference.
>
>
OK, now you can all take ten house points for getting into a jargon
pissing contest.

Steve Holden

unread,
Feb 6, 2008, 11:51:04 AM2/6/08
to pytho...@python.org, Grant Edwards, pytho...@python.org
Reedick, Andrew wrote:
>> -----Original Message-----
>> From: python-list-bounces+jr9445=att...@python.org [mailto:python-
>> list-bounces+jr9445=att...@python.org] On Behalf Of Grant Edwards
>> Sent: Wednesday, February 06, 2008 10:35 AM
>> To: pytho...@python.org
>> Subject: Re: Why not a Python compiler?
>>
>> On 2008-02-06, Reedick, Andrew <jr9...@ATT.COM> wrote:
>>
>>>> Pypy is a very ambitious project and it aims, amongst many
>>>> other goals, to provide a fast just-in-time python
>>>> implementation. They even say that the "secret goal is being
>>>> faster than c, which is nonsense, isn´t it?" (I still didn´t
>>>> get the joke though...).
>>> 'c' is also the speed of light.
>> 'c' is the speed of light _in_a_vacuum_.
>
> True.

>
>
>>> And since nothing can travel faster than light...
>> Nothing can travel faster than the speed of light
>> _in_a_vacuum_. There are situtaitons where things can (and
>> regularly do) travel faster than light:
>> http://en.wikipedia.org/wiki/Cherenkov_radiation
>
>
> Nope. It propagates, not travels, faster than light. Go ask a physicist to explain it. It's odd...
>
>
>>> One demerit has been marked against your geek card for missing
>>> an obvious science pun. Additionally, your membership to the
>>> Star Trek Lifestyle Adventure Club has been put on
>>> probationary status for the next twelve parsecs.
>> Ouch. Two demerits for using the distance unit "parsec" in a
>> context where a quantity of time was required.
>
>

Carl Friedrich Bolz

unread,
Feb 6, 2008, 12:14:40 PM2/6/08
to Reedick, Andrew, pytho...@python.org, "Luis M. González"
Reedick, Andrew wrote:
>> -----Original Message-----
>> From: python-list-bounces+jr9445=att...@python.org [mailto:python-
>> list-bounces+jr9445=att...@python.org] On Behalf Of Luis M. González
>> Sent: Tuesday, February 05, 2008 6:44 PM
>> To: pytho...@python.org
>> Subject: Re: Why not a Python compiler?
>>
>>
>> Pypy is a very ambitious project and it aims, amongst many other
>> goals, to provide a fast just-in-time python implementation.
>> They even say that the "secret goal is being faster than c, which is
>> nonsense, isn´t it?" (I still didn´t get the joke though...).
>>
>
> 'c' is also the speed of light. And since nothing can travel faster than light...

nice theory, but wrong: The PyPy home page uses a capital letter C:

http://codespeak.net/pypy/dist/pypy/doc/home.html

Cheers,

Carl Friedrich Bolz

Carl Friedrich Bolz

unread,
Feb 6, 2008, 12:14:40 PM2/6/08
to pytho...@python.org, pytho...@python.org, "Luis M. González"
Reedick, Andrew wrote:
>> -----Original Message-----
>> From: python-list-bounces+jr9445=att...@python.org [mailto:python-
>> list-bounces+jr9445=att...@python.org] On Behalf Of Luis M. González
>> Sent: Tuesday, February 05, 2008 6:44 PM
>> To: pytho...@python.org
>> Subject: Re: Why not a Python compiler?
>>
>>
>> Pypy is a very ambitious project and it aims, amongst many other
>> goals, to provide a fast just-in-time python implementation.
>> They even say that the "secret goal is being faster than c, which is
>> nonsense, isn´t it?" (I still didn´t get the joke though...).
>>
>

Carl Friedrich Bolz

unread,
Feb 6, 2008, 1:16:48 PM2/6/08
to Luis M. Gonzalez, pytho...@python.org
Hi Luis,

Luis M. Gonzalez wrote:
> Well, lets suppose that being faster than C is the real goal...

How about we call it a very long-term dream?

> Are you confident that it will be reached?

We have ideas how to get there, but it is really rather long-term. There
will be a lot of research needed to achieve that for sure.

> How far is it at this moment?

Since a year already we have a JIT that makes quite fast code for purely
integer-type operations. Quite fast meaning about the speed of gcc -O0.
So far it is not faster than Psyco (it supports generators, though). We
are confident that the JIT will get substantially better this year
(probably better than Psyco). Where exactly this will leave us we don't
know.

> I've been following the project but the scarcity of news is getting me
> anxious...

Read the blog: morepypy.blogspot.com :-)

Cheers,

Carl Friedrich

Carl Friedrich Bolz

unread,
Feb 6, 2008, 1:16:48 PM2/6/08
to pytho...@python.org, pytho...@python.org

Jorge Godoy

unread,
Feb 6, 2008, 4:55:03 PM2/6/08
to
Reedick, Andrew wrote:

>> -----Original Message-----
>> From: python-list-bounces+jr9445=att...@python.org [mailto:python-
>> list-bounces+jr9445=att...@python.org] On Behalf Of Grant Edwards
>>

>> Nothing can travel faster than the speed of light
>> _in_a_vacuum_. There are situtaitons where things can (and
>> regularly do) travel faster than light:
>> http://en.wikipedia.org/wiki/Cherenkov_radiation
>
>
> Nope. It propagates, not travels, faster than light. Go ask a physicist
> to explain it. It's odd...

So let me see if I understood this correctly: C travels, C++ propagates? :-)


Steven D'Aprano

unread,
Feb 6, 2008, 6:45:14 PM2/6/08
to
On Wed, 06 Feb 2008 10:14:10 -0600, Reedick, Andrew wrote:

>> > 'c' is also the speed of light.
>>
>> 'c' is the speed of light _in_a_vacuum_.
>
> True.
>
>
>> > And since nothing can travel faster than light...
>>
>> Nothing can travel faster than the speed of light _in_a_vacuum_. There
>> are situtaitons where things can (and regularly do) travel faster than
>> light: http://en.wikipedia.org/wiki/Cherenkov_radiation
>
>
> Nope. It propagates, not travels, faster than light. Go ask a
> physicist to explain it. It's odd...

Propagate, travel, what's the difference?

If you're referring to the fact that in non-vacuum, light travels more
slowly due to frequent interactions with the particles of the medium it
travels through, that's discussed in the Wikipedia article.

There are quite a number of superluminal (faster than light) phenomena.
See, for example:

http://en.wikipedia.org/wiki/Slow_light
http://en.wikipedia.org/wiki/Phase_velocity
http://en.wikipedia.org/wiki/Faster-than-light

particularly the section titled:

"Superficially FTL phenomena which do not carry information"


--
Steven

Gary Duzan

unread,
Feb 6, 2008, 11:46:28 AM2/6/08
to
In article <13qjktd...@corp.supernews.com>,

No demerits for Andrew; it is a Star Wars reference, which is
quite on topic for this subthread.

http://starwars.wikia.com/wiki/Kessel_Run

Gary Duzan
Motorola H&NM


Stefan Behnel

unread,
Feb 7, 2008, 5:03:12 AM2/7/08
to Santiago Romero
Santiago Romero wrote:
> I'm impressed with python. I'm very happy with the language and I
> find Python+Pygame a very powerful and productive way of writing 2D
> games. I'm not, at this moment, worried about execution speed of the
> small game I'm working on (it runs at full 60 fps even in an old AMD-
> K6 450 Laptop computer), but I continue asking me the same question:
>
> Why not a Python COMPILER?
>
> It would be very nice to be able to output Linux, MAC or Windows
> binaries of compiled (not bytecompiled) code. It would run faster, it
> will be smaller in size (I think)

Take a look at Cython. It's an optimising Python-to-C compiler for writing
Python extensions. So you can basically take a Python module and compile it to
C code that runs against the CPython runtime.

http://cython.org/


> and it will be easy to distribute to
> people not having python installed. Yes, I know about py2exe, but I'm
> not sure if that's the right aproach.

That's a different focus, but then, there's "portable Python".

http://www.portablepython.com/

Stefan

Jean-Paul Calderone

unread,
Feb 7, 2008, 6:36:24 AM2/7/08
to pytho...@python.org
On Thu, 07 Feb 2008 11:03:12 +0100, Stefan Behnel <stef...@behnel.de> wrote:
>Santiago Romero wrote:
> [snip]

>>
>> Why not a Python COMPILER?
>>
>> It would be very nice to be able to output Linux, MAC or Windows
>> binaries of compiled (not bytecompiled) code. It would run faster, it
>> will be smaller in size (I think)
>
>Take a look at Cython. It's an optimising Python-to-C compiler for writing
>Python extensions. So you can basically take a Python module and compile it to
>C code that runs against the CPython runtime.
>
>http://cython.org/
>

It's a not-quite-Python-to-C compiler. I don't think it is an optimizing
compiler either. Can you provide a reference for this?

Jean-Paul

Ryszard Szopa

unread,
Feb 7, 2008, 8:07:27 AM2/7/08
to
On Feb 5, 9:30 am, cokofree...@gmail.com wrote:

> I don't know the exact details but I think the issue is the dynamic
> nature of Python makes it impossible to correctly store the various
> types and changes into compiled code. Someone else will probably be
> able to provide a good reason as to why it isn't very feasible, nor a
> good idea. If you want to speed up your python look at Psyco. http://psyco.sourceforge.net/

Yeah, but exactly what features make it so hard to write a compiler
for Python?

Common Lisp seems like a language at least as dynamic as Python, e.g.
you can change the type of objects at runtime, you can make changes to
functions, you can change classes at runtime, you can add methods and
generic functions (nb. these changes are reflected in existing
objects), you have a metaobject protocol. Moreover, you have
multimethods (in Python you don't, so it is one less thing to care).
However, Common Lisp has a few decent compilers (at least two open
source and two commercial).

Google tells me that such arguments have been raised back in 2001 [1].
I can add from myself that today Python is much more similar to Common
Lisp than in 2001. For example, multiple inheritance in Python >= 2.3
behaves like in Dylan, which in turn behaves like CLOS with a twist.

What is more, apparently there is a Python compiler via CL: CLPython
(I don't have access to ACL, however, so I can't verify the claims of
the authors).

Finally, speaking of JIT compilers: recently has appeared something
that looks like avery nice JIT compiler for Scheme, Ikarus [3].
Scheme is also quite dynamical, but is not OO, so I don't know how
viable is the analogy.

Of course, when writing Python extensions in C is fairly easy and when
rewriting just the critical part of the code is enough to get
acceptable performance, I really doubt I will see anybody willing to
invest serious amounts of money and time into writing a native
compiler for Python. Learning C cannot be so hard ;-). Also, this
seems consistent with Python viewed as a glue between libraries
written in C.


Cheers,

-- Richard

BIG FAT DISCLAIMER: I DO NOT want to start a "Python vs. Common Lisp
and Scheme" flame war.

[1] http://mail.python.org/pipermail/python-list/2001-April/080394.html
[2] http://common-lisp.net/project/clpython/
[3] http://www.cs.indiana.edu/~aghuloum/ikarus/

Steve Holden

unread,
Feb 7, 2008, 9:06:32 AM2/7/08
to pytho...@python.org
Ryszard Szopa wrote:
> On Feb 5, 9:30 am, cokofree...@gmail.com wrote:
>
>> I don't know the exact details but I think the issue is the dynamic
>> nature of Python makes it impossible to correctly store the various
>> types and changes into compiled code. Someone else will probably be
>> able to provide a good reason as to why it isn't very feasible, nor a
>> good idea. If you want to speed up your python look at Psyco. http://psyco.sourceforge.net/
>
> Yeah, but exactly what features make it so hard to write a compiler
> for Python?
> [...]

a. People tell me writing a compiler for Python is hard.

b. It's certainly way to hard for me.

c. But hey, I've heard about this neat language called Common Lisp that
has a compiler. It looks a lot like Python.

d. So why can't you brainboxes write a compiler for Python?

Please tell me if I'm missing anything from this summary of your thought
processes.

Bjoern Schliessmann

unread,
Feb 7, 2008, 10:19:21 AM2/7/08
to
Ryszard Szopa wrote:

> Of course, when writing Python extensions in C is fairly easy and
> when rewriting just the critical part of the code is enough to get
> acceptable performance, I really doubt I will see anybody willing
> to invest serious amounts of money and time into writing a native
> compiler for Python. Learning C cannot be so hard ;-).

Sure! Learning English also is not too hard. So everyone should be
capable of writing poetry of Shakespeare niveau.

Regards,


Björn

--
BOFH excuse #69:

knot in cables caused data stream to become twisted and kinked

Stefan Behnel

unread,
Feb 7, 2008, 10:31:54 AM2/7/08
to Bjoern Schliessmann
Bjoern Schliessmann wrote:
> Learning English also is not too hard. So everyone should be
> capable of writing poetry of Shakespeare niveau.

You're lucky that you can infer anything from a wrong statement.

http://www.mipmip.org/tidbits/pronunciation.shtml

Stefan

joseph...@gmail.com

unread,
Feb 7, 2008, 10:51:57 AM2/7/08
to
On Feb 7, 9:06 am, Steve Holden <st...@holdenweb.com> wrote:
> Ryszard Szopa wrote:
> > On Feb 5, 9:30 am, cokofree...@gmail.com wrote:
>
> >> I don't know the exact details but I think the issue is the dynamic
> >> nature of Python makes it impossible to correctly store the various
> >> types and changes into compiled code. Someone else will probably be
> >> able to provide a good reason as to why it isn't very feasible, nor a
> >> good idea. If you want to speed up your python look at Psyco.http://psyco.sourceforge.net/

>
> > Yeah, but exactly what features make it so hard to write a compiler
> > for Python?
> > [...]
>
> a. People tell me writing a compiler for Python is hard.
>
> b. It's certainly way to hard for me.
>
> c. But hey, I've heard about this neat language called Common Lisp that
> has a compiler. It looks a lot like Python.
>
> d. So why can't you brainboxes write a compiler for Python?
>
> Please tell me if I'm missing anything from this summary of your thought
> processes.
>

The basic difference is in point c. Common Lisp was a standard arrived
at by discussions including people who spent the 1970s and 1980s
developing high-performance native-code Lisp compilers targeting
conventional architectures (e.g. PDP-10, VAX, Sun workstations, etc.).
Stuff that would be hard to support with compiled code on conventional
CPUs was discouraged by the process.

The semantics of the Common Lisp standard were developed with the
needs of compilers in mind. CLOS is a very powerful object system, but
the design was developed with compilation and efficiency concerns in
mind. One major difference from Python OOP (as I understand it): CLOS
methods are looked up by their global method name. Python methods
(IIRC) are looked up in per-instance dictionaries. Redefining CLOS
methods requires changing one method-dispatch cache, and is supported
through a high-level interface, which a compiler can translate into
the low-level implementation machinery. Python code can mash the
dictionaries at will, because the low-level machinery is exposed.

The details, if I have mis-stated them, are not as important as the
principle of original design intent I am trying to illustrate.

Stefan Behnel

unread,
Feb 7, 2008, 10:52:57 AM2/7/08
to Jean-Paul Calderone
Jean-Paul Calderone wrote:
> On Thu, 07 Feb 2008 11:03:12 +0100, Stefan Behnel <stef...@behnel.de>
> wrote:
>> Take a look at Cython. It's an optimising Python-to-C compiler for
>> writing
>> Python extensions. So you can basically take a Python module and
>> compile it to
>> C code that runs against the CPython runtime.
>>
>> http://cython.org/
>
> It's a not-quite-Python-to-C compiler.

Ok, there are differences. For example, you can't define functions dynamically
(it doesn't currently support closures anyway). But it already supports a much
wider subset of the language than Pyrex originally did. For example, you can
use list comprehensions and Python 3 keyword-only arguments in function
signatures. I would expect it would compile quite a lot of Python code out
there without or with only minor modifications.


> I don't think it is an optimizing
> compiler either. Can you provide a reference for this?

It optimises a lot of common patterns into very fast sequences of Python API
calls (or even generates specialised non-API code for them). It also generates
optimised runtime code for special cases based on the type of an object (e.g.
if the object you iterate turns out to be a list, it uses fast list API calls
in loops, and a standard iterator otherwise). So the generated code is usually
much faster than what Pyrex gives you. Robert and I had an optimise session
lately where we dropped the function call-overhead by some 20-50% (!) compared
to the preceding Cython version (not even to Pyrex), just depending on the
signature.

I think that qualifies for an "optimising" compiler.

Stefan

Grant Edwards

unread,
Feb 7, 2008, 3:05:58 PM2/7/08
to

Silly me.

I wonder if George Lucas intended it as a joke or if he thought
a parsec was a unit of time.

--
Grant Edwards grante Yow! Clear the laundromat!!
at This whirl-o-matic just had
visi.com a nuclear meltdown!!

Torsten Bronger

unread,
Feb 7, 2008, 3:31:40 PM2/7/08
to
Hallöchen!

Grant Edwards writes:

> On 2008-02-06, Gary Duzan <mgi...@motorola.com> wrote:
>
>> In article <13qjktd...@corp.supernews.com>,
>>
>> Grant Edwards <gra...@visi.com> wrote:
>>

>>> [...]


>>>
>>> Ouch. Two demerits for using the distance unit "parsec" in a
>>> context where a quantity of time was required.
>>
>> No demerits for Andrew; it is a Star Wars reference, which is
>> quite on topic for this subthread.
>>
>> http://starwars.wikia.com/wiki/Kessel_Run
>
> Silly me.
>
> I wonder if George Lucas intended it as a joke or if he thought
> a parsec was a unit of time.

The latter because it was corrected in the novelization.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: bro...@jabber.org
(See http://ime.webhop.org for further contact info.)

Ivan Van Laningham

unread,
Feb 7, 2008, 3:44:05 PM2/7/08
to pytho...@python.org
Gary Kurtz at SunCon 77 explained that it was a test to see if Obi-Wan
knew what he was doing; supposedly, Obi-Wan's expression indicated
that he knew Solo was feeding him shit.

I think Lucas didn't have a clue, myself; it's not credible that
citizens of a starfaring civilization who deliberately set out to hire
a starship wouldn't know the difference between time and distance.
Occam's razor says Lucas screwed up and doesn't want to admit it.

Metta,
Ivan

> --
> http://mail.python.org/mailman/listinfo/python-list
>

--
Ivan Van Laningham
God N Locomotive Works
http://www.pauahtun.org/
http://www.python.org/workshops/1998-11/proceedings/papers/laningham/laningham.html
Army Signal Corps: Cu Chi, Class of '70
Author: Teach Yourself Python in 24 Hours

Reedick, Andrew

unread,
Feb 7, 2008, 4:07:19 PM2/7/08
to pytho...@python.org
> -----Original Message-----
> From: python-list-bounces+jr9445=att...@python.org [mailto:python-
> list-bounces+jr9445=att...@python.org] On Behalf Of Torsten Bronger
> Sent: Thursday, February 07, 2008 3:32 PM
> To: pytho...@python.org
> Subject: Re: Why not a Python compiler?
>
> >
> > I wonder if George Lucas intended it as a joke or if he thought
> > a parsec was a unit of time.
>
> The latter because it was corrected in the novelization.
>

Errr... didn't one of the novels explain it away by describing the
kessel run as a region of space warped by black holes or other objects?
Bragging rights for crossing such a field thus centered on shortest
distance instead of time.

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623


Lou Pecora

unread,
Feb 7, 2008, 4:21:04 PM2/7/08
to
In article <87tzkko...@physik.rwth-aachen.de>,
Torsten Bronger <bro...@physik.rwth-aachen.de> wrote:

> > a parsec was a unit of time.
>
> The latter because it was corrected in the novelization.
>
> Tschö,
> Torsten.

Sounds like one. The reverse of light year that sounds like a unit of
time, but isn't. I've heard it used seriously like time in some movie.

--
-- Lou Pecora

Steven D'Aprano

unread,
Feb 7, 2008, 4:25:34 PM2/7/08
to
On Thu, 07 Feb 2008 13:44:05 -0700, Ivan Van Laningham wrote:

> Gary Kurtz at SunCon 77 explained that it was a test to see if Obi-Wan
> knew what he was doing; supposedly, Obi-Wan's expression indicated that
> he knew Solo was feeding him shit.

Why the hell would the pilot care whether the passengers knew what a
parsec was? Did Concorde pilots quiz their passengers what Mach 1 means?

Especially a pirate like Solo, who really only cared about one question:
"can the passenger pay?".


> I think Lucas didn't have a clue, myself; it's not credible that
> citizens of a starfaring civilization who deliberately set out to hire a
> starship wouldn't know the difference between time and distance. Occam's
> razor says Lucas screwed up and doesn't want to admit it.

For sure.


--
Steven

Steven D'Aprano

unread,
Feb 7, 2008, 4:27:33 PM2/7/08
to
On Thu, 07 Feb 2008 09:06:32 -0500, Steve Holden wrote:

> Ryszard Szopa wrote:
>> On Feb 5, 9:30 am, cokofree...@gmail.com wrote:
>>
>>> I don't know the exact details but I think the issue is the dynamic
>>> nature of Python makes it impossible to correctly store the various
>>> types and changes into compiled code. Someone else will probably be
>>> able to provide a good reason as to why it isn't very feasible, nor a
>>> good idea. If you want to speed up your python look at Psyco.
>>> http://psyco.sourceforge.net/
>>
>> Yeah, but exactly what features make it so hard to write a compiler for
>> Python?
>> [...]
>
> a. People tell me writing a compiler for Python is hard.
>
> b. It's certainly way to hard for me.
>
> c. But hey, I've heard about this neat language called Common Lisp that
> has a compiler. It looks a lot like Python.
>
> d. So why can't you brainboxes write a compiler for Python?
>
> Please tell me if I'm missing anything from this summary of your thought
> processes.


Be fair -- he's asking what specific features of Python make it hard.
That's a reasonable question.


--
Steven

Jeroen Ruigrok van der Werven

unread,
Feb 7, 2008, 4:30:55 PM2/7/08
to Reedick, Andrew, pytho...@python.org
-On [20080207 22:09], Reedick, Andrew (jr9...@ATT.COM) wrote:
>Errr... didn't one of the novels explain it away by describing the
>kessel run as a region of space warped by black holes or other objects?
>Bragging rights for crossing such a field thus centered on shortest
>distance instead of time.

http://starwars.wikia.com/wiki/Kessel_Run

Han Solo claimed that his Millennium Falcon "made the Kessel Run in less
than twelve parsecs." The parsec is a unit of distance, not time. Solo was
not referring directly to his ship's speed when he made this claim. Instead,
he was referring to the shorter route he was able to travel by skirting the
nearby Maw black hole cluster, thus making the run in under the standard
distance. However, parsec relates to time in that a shorter distance equals
a shorter time at the same speed. By moving closer to the black holes, Solo
managed to cut the distance down to about 11.5 parsecs.

In the A New Hope novelization, Han says "standard time units" rather than
"parsecs". Therefore, the reduced distance of Solo's Kessel Run is most
likely a retcon to explain George Lucas's confusion of time and distance
units.

--
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/
A place for everything, and everything in its place...

Erik Max Francis

unread,
Feb 7, 2008, 5:34:50 PM2/7/08
to
Ivan Van Laningham wrote:

> Gary Kurtz at SunCon 77 explained that it was a test to see if Obi-Wan
> knew what he was doing; supposedly, Obi-Wan's expression indicated
> that he knew Solo was feeding him shit.
>
> I think Lucas didn't have a clue, myself; it's not credible that
> citizens of a starfaring civilization who deliberately set out to hire
> a starship wouldn't know the difference between time and distance.
> Occam's razor says Lucas screwed up and doesn't want to admit it.

Indeed, that is precisely what I would have said. Any after-the-fact
explanation of why the error was present (but not corrected or pointed
out in the movie) is just so much rationalization.

--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 18 N 121 57 W && AIM, Y!M erikmaxfrancis
So little time, so little to do.
-- Oscar Levant