Why not a Python compiler?

[Gary Duzan]

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

Gary Duzan
Motorola H&NM

 

[Steve Holden]

-----Original Message-----
From: [email protected] [mailtoython-
[email protected]] On Behalf Of Grant Edwards
Sent: Wednesday, February 06, 2008 10:35 AM
To: (e-mail address removed)
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.

'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...

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.

regards
Steve

 

[Steve Holden]

-----Original Message-----
From: [email protected] [mailtoython-
[email protected]] On Behalf Of Grant Edwards
Sent: Wednesday, February 06, 2008 10:35 AM
To: (e-mail address removed)
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.

'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...

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.

regards
Steve

 

[Carl Friedrich Bolz]

-----Original Message-----
From: [email protected] [mailtoython-
[email protected]] On Behalf Of Luis M. González
Sent: Tuesday, February 05, 2008 6:44 PM
To: (e-mail address removed)
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]

-----Original Message-----
From: [email protected] [mailtoython-
[email protected]] On Behalf Of Luis M. González
Sent: Tuesday, February 05, 2008 6:44 PM
To: (e-mail address removed)
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]

Hi Luis,

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]

Hi Luis,

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

 

[Jorge Godoy]

-----Original Message-----
From: [email protected] [mailtoython-
[email protected]] 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]

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"

 

[Stefan Behnel]

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

 

[Ryszard Szopa]

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]

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.

regards
Steve

 

[Bjoern Schliessmann]

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

 

[Stefan Behnel]

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

 

[josephoswald+gg]

On Feb 5, 9:30 am, (e-mail address removed) wrote:

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.

 

[Grant Edwards]

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.

 

[Torsten Bronger]

Hallöchen!

[...]

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.

 

[Ivan Van Laningham]

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

Silly me.

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

--
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]

-----Original Message-----

From: [email protected] [mailtoython-
[email protected]] On Behalf Of Torsten Bronger
Sent: Thursday, February 07, 2008 3:32 PM
To: (e-mail address removed)
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]

a parsec was a unit of time.

The latter because it was corrected in the novelization.

Tschö,
Torsten.[/QUOTE]

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.