Python compilers?

[Svein Ove Aas]

Is anyone working on a python-to-native compiler?
I'd be interested in taking a look.

Come to think of it, is anyone working on a sexpr-enabled version of
Python, or anything similar? I really miss my macros whenever I try to
use it...

[Harry George]

Svein Ove Aas <sv************ @brage.info> writes:

Mitja wrote:

Thorsten Kampe <th******@thors tenkampe.de>
(news:1m******* ********@thorst enkampe.de) wrote:

* Tor Iver Wilhelmsen (2004-05-18 17:26 +0100)
Grant Edwards <gr****@visi.co m> writes:

> Dude, didn't you take high-school math? 1/3 _is_ 0.33333...

No, because at some point you will stop writing 3's, either out of
boredom, exhaustion or because you need to pee. At that instant, you
introduce a rounding error, making 3 * 1/3 = 0.99999999999.. . instead
of 1.0

Must have been a long time since you went to school... 1/3 is
/exactly/ 0.3...: http://mathworld.wolfram.com/RepeatingDecimal.html

Even worse....
0.9999999999999 99999999... is exactly 1 :)

Only for infinite counts of '9', and computers don't do infinity.

We need to stop randomly mixing exact math with computer
implementations (and approximations) thereof.

"<digit><digit> ..." is the accepted ASCII rendition of the repeating
overbar, and thus explicitly means "on to infinity". 0.99... exactly
equals 1.

If you want to shift the discussion to computer implementations then
that is a different story. We can talk binary representations of
decimal fractions, and the value of rationals as a useful
representation.

But why not also complain that Python does not have a complete
representation of pi. After all, the value of pi is known to well
beyond the IEEE 80-bit or 64-bit or whatever that an implementation
provides. Even if we did mp math and did really long pi
representations , they would of course not be exact. "e" isn't handled
completely either. Why not complain about those?

We don't complain because the available values are "good enough".
IEEE 764 64-bit reals (internally handled as IEEE 764 80-bit) are
good-enough for most numerical needs. I'll admit, the US debt needs
some extended precision :-( but most numerical analysis gets by with
epsilons under 1e-14.

Hey, while we are on the subject of exact representation, what's with
multithreading? My computer has only one CPU. What's going on
here???? It's a lie, a LIE I tell you...

--
ha************@ boeing.com
6-6M21 BCA CompArch Design Engineering
Phone: [phone]

[Carl Banks]

Paul Rubin <http://ph****@NOSPAM.i nvalid> wrote in message news:<7x******* *****@ruckus.br ouhaha.com>...

Carl Banks <im*****@aerojo ckey.invalid> writes:

I don't follow you. In what way is Python dynamic that Lisp isn't?

class foo: ... def bar(self, x):
... return x*x
... a = foo()
a.bar(3) 9 a.bar = lambda x: x*x*x
a.bar(3) 27

Well, come on, of course there's going to be some things here and
there you can do in one and not the other. In wat is Python dynamic
that Lisp isn't to such an extent that it would cripple any attempts
to compile it?
--
CARL BANKS

[Heather Coppersmith]

On 19 May 2004 14:54:48 -0700,
im*****@aerojoc key.com (Carl Banks) wrote:

Paul Rubin <http://ph****@NOSPAM.i nvalid> wrote in message
news:<7x******* *****@ruckus.br ouhaha.com>...

Carl Banks <im*****@aerojo ckey.invalid> writes:

> I don't follow you. In what way is Python dynamic that Lisp isn't?

>>> class foo:

... def bar(self, x):
... return x*x
...

>>> a = foo()
>>> a.bar(3)

9

>>> a.bar = lambda x: x*x*x
>>> a.bar(3)

27

>>>

Well, come on, of course there's going to be some things here
and there you can do in one and not the other. In wat is Python
dynamic that Lisp isn't to such an extent that it would cripple
any attempts to compile it?

It's not a matter of not being able to compile python; it's a
matter of what sort of benefits you'd gain.

For example:

if x.y.z == a.b.c:
print 'equal'

What is x.y.z? Who knows? The object to which x is bound might
create y on the fly, based on information not available to the
compiler (see __getattr__ and properties). Once the run-time
system asks object x for attribute y, it (the run-time) has to go
through the whole process again to determine z (and, therefore,
x.y.z). Similar for a.b.c, and any of that code might have
redefined what it means for such objects to be equal, which means
that the compiler can't even know what sorts of equality tests
might be available at the time that the code executes, let alone
generate a simple compare instruction.

This is important: There is little, if any, difference between
that code and running everything through the interpreter anyway.

For that matter, simply accessing x.y might change a.b. (FWIW,
though, the ensuing programmer-cide would be entirely justified.)

"Plain" Common Lisp code has (mostly) the same issues, but
performance critical Common Lisp programs contain strategically
placed type declarations (thus reducing the dynamicity of the
language) to help the compiler to know what it's up against.

There are proposals to add type declarations to Python; google is
your friend (see also 'decorators'). Similar for JIT compilers
(psyco falls into this category).

Regards,
Heather

--
Heather Coppersmith
That's not right; that's not even wrong. -- Wolfgang Pauli

[Paul Rubin]

im*****@aerojoc key.com (Carl Banks) writes:

>> a.bar = lambda x: x*x*x
>> a.bar(3)

27

Well, come on, of course there's going to be some things here and
there you can do in one and not the other. In wat is Python dynamic
that Lisp isn't to such an extent that it would cripple any attempts
to compile it?

The example above kills any attempt to turn a.bar() into a static
procedure call. There's more like it, e.g. the existence of the
locals() dictionary and the ability to modify it. However, it should
be possible to define a reasonable subset of Python that can compile
into good code. The stuff that makes compilation difficult makes the
code unmaintainable too.

I do think that Python's designers should wait til PyPy with
native-code backends has been deployed for a while before defining too
much of Python 3.0, so we can first gain some experience with compiled
Python. Python should evolve towards being compiled most of the time.

[Carl Banks]

Paul Rubin wrote:

im*****@aerojoc key.com (Carl Banks) writes:

> >>> a.bar = lambda x: x*x*x
> >>> a.bar(3)
> 27
Well, come on, of course there's going to be some things here and
there you can do in one and not the other. In wat is Python dynamic
that Lisp isn't to such an extent that it would cripple any attempts
to compile it?

The example above kills any attempt to turn a.bar() into a static
procedure call.

Of course it does--but it's one method. A compiler, if it's good,
would only make the optization on methods named "bar", and it could
probably pare the number of possible classes it could happen to down
to only a few.

I mean you could have a Turing nightmare on your hands, with all kinds
of crazy setattrs and execs and stuff, in both Python and Lisp, and
then there's not much a compiler could do but emit totally general
code. I assume Lisp compilers do this sometimes.

There's more like it, e.g. the existence of the
locals() dictionary and the ability to modify it.
New feature? I didn't think modifying the dict returned by locals
affected the variables.

However, it should
be possible to define a reasonable subset of Python that can compile
into good code. The stuff that makes compilation difficult makes the
code unmaintainable too.
True, but even if you didn't do that, I think a compiler could do a
decent job with reasonable code.

I do think that Python's designers should wait til PyPy with
native-code backends has been deployed for a while before defining too
much of Python 3.0, so we can first gain some experience with compiled
Python. Python should evolve towards being compiled most of the time.

Agreed
--
CARL BANKS http://www.aerojockey.com/software
"If you believe in yourself, drink your school, stay on drugs, and
don't do milk, you can get work."
-- Parody of Mr. T from a Robert Smigel Cartoon

[Paul Rubin]

Carl Banks <im*****@aerojo ckey.invalid> writes:

The example above kills any attempt to turn a.bar() into a static
procedure call.
Of course it does--but it's one method. A compiler, if it's good,
would only make the optization on methods named "bar", and it could
probably pare the number of possible classes it could happen to down
to only a few.

How could it possibly know? The reassignment of a.bar could happen
anytime, anywhere in the code. Maybe even in an eval.
I mean you could have a Turing nightmare on your hands, with all kinds
of crazy setattrs and execs and stuff, in both Python and Lisp, and
then there's not much a compiler could do but emit totally general
code. I assume Lisp compilers do this sometimes.

Lisp compilers might have to do that sometimes, but Python compilers
would have to do it ALL the time. Psyco took one way out, basically
generating code at runtime and caching it for specific operand types,
but the result is considerable code expansion compared to precompilation.

[Konstantin Veretennicov]

Carl Banks <im*****@aerojo ckey.invalid> wrote in message news:<38******* ********@fe2.co lumbus.rr.com>. ..

There's more like it, e.g. the existence of the
locals() dictionary and the ability to modify it.

New feature? I didn't think modifying the dict returned by locals
affected the variables.

Evidence of crime :)

Python 2.3.2

x Traceback (most recent call last):
File "<stdin>", line 1, in ?
NameError: name 'x' is not defined locals()['x'] = 1
x

1
Not to mention stack frame magic available via inspect.*...
- kv

[Duncan Booth]

kv***********@y ahoo.com (Konstantin Veretennicov) wrote in
news:51******** *************** ***@posting.goo gle.com:

Carl Banks <im*****@aerojo ckey.invalid> wrote in message
news:<38******* ********@fe2.co lumbus.rr.com>. ..

> There's more like it, e.g. the existence of the
> locals() dictionary and the ability to modify it.

New feature? I didn't think modifying the dict returned by locals
affected the variables.

Evidence of crime :)

Python 2.3.2

x Traceback (most recent call last):
File "<stdin>", line 1, in ?
NameError: name 'x' is not defined locals()['x'] = 1
x 1

That works because you are using locals() to access your global variables.
Put the same code in a function and it behaves differently:

def test(): .... x = 0
.... locals()['x'] = 1
.... print x
.... test()

0

You cannot depend on the behaviour of modifying locals() remaining
unchanged over different releases of Python. Bottom line: don't do this.

[Michael Hudson]

kv***********@y ahoo.com (Konstantin Veretennicov) writes:

Carl Banks <im*****@aerojo ckey.invalid> wrote in message news:<38******* ********@fe2.co lumbus.rr.com>. ..

There's more like it, e.g. the existence of the
locals() dictionary and the ability to modify it.
New feature? I didn't think modifying the dict returned by locals
affected the variables.

Evidence of crime :)

Python 2.3.2

x Traceback (most recent call last):
File "<stdin>", line 1, in ?
NameError: name 'x' is not defined locals()['x'] = 1
x

1
Not to mention stack frame magic available via inspect.*...

Well, fortunately *this* level of gimmickery is already somewhat
forbidden...

Cheers,
mwh

-- so python will fork if activestate starts polluting it?

I find it more relevant to speculate on whether Python would fork
if the merpeople start invading our cities riding on the backs of
giant king crabs. -- Brian Quinlan, comp.lang.pytho n

[Ville Vainio]

>>>>> "Paul" == Paul Rubin <http://ph****@NOSPAM.i nvalid> writes:

Paul> I do think that Python's designers should wait til PyPy with
Paul> native-code backends has been deployed for a while before
Paul> defining too much of Python 3.0, so we can first gain some
Paul> experience with compiled Python. Python should evolve
Paul> towards being compiled most of the time.

I think we might be able to get significant benefits from the .NET
implementation (provided that Mono would prove to be legally feasible
in the future) - a lot of the JIT work is done by "other people", and
being able to seamlessly combine Python with a statically typed
language (which probably produces faster code) would be able to give
Python a sweet role in many programming projects - the role of the
initial implementation/specification language, with grunts doing the
possible mechanical porting of performance critical areas.

We could have such a role already, but only in theory. C/C++
integration is not seamless enough, and the languages themselves are
considered to be too difficult, clumsy and unproductive to attract
companies.

One thing is pretty certain to benefit any future speedup efforts,
whatever road is chosen, namely optional type declarations. Their
implementation could be left unspecified, and the initial Python
implementation could use them only for runtime type checking in
debugmode (or ignore altogether). Type inferencing could also use them
to smooth up things.

--
Ville Vainio http://tinyurl.com/2prnb