PyPy 1.0: JIT compilers for free and more

[Carl Friedrich Bolz]

==========================================
PyPy 1.0: JIT compilers for free and more
==========================================

Welcome to the PyPy 1.0 release - a milestone integrating the results
of four years of research, engineering, management and sprinting
efforts, concluding the 28 months phase of EU co-funding!

Although still not mature enough for general use, PyPy 1.0 materializes
for the first time the full extent of our original vision:

- A flexible Python interpreter, written in "RPython":

- Mostly unaware of threading, memory and lower-level target platform
aspects.
- Showcasing advanced interpreter features and prototypes.
- Passing core CPython regression tests, translatable to C, LLVM and
..NET.

- An advanced framework to translate such interpreters and programs:

- That performs whole type-inference on RPython programs.
- Can weave in threading, memory and target platform aspects.
- Has low level (C, LLVM) and high level (CLI, Java, JavaScript)
backends.

- A **Just-In-Time Compiler generator** able to **automatically**
enhance the low level versions of our Python interpreter, leading to
run-time machine code that runs algorithmic examples at speeds typical
of JITs!

Previous releases, particularly the 0.99.0 release from February,
already highlighted features of our Python implementation and the
abilities of our translation approach but the **new JIT generator**
clearly marks a major research result and gives weight to our vision
that one can generate efficient interpreter implementations, starting
from a description in a high level language.

We have prepared several entry points to help you get started:

* The main entry point for JIT documentation and status:

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

* The main documentation and getting-started PyPy entry point:

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

* Our online "play1" demos showcasing various Python interpreters,
features (and a new way to program AJAX applications):

http://play1.codespeak.net/

* Our detailed and in-depth Reports about various aspects of the
project:

http://codespeak.net/pypy/dist/pypy/doc/index-report.html

In the next few months we are going to discuss the goals and form of
the next stage of development - now more than ever depending on your
feedback and contributions - and we hope you appreciate PyPy 1.0 as an
interesting basis for greater things to come, as much as we do
ourselves!

have fun,

the PyPy release team,
Samuele Pedroni, Armin Rigo, Holger Krekel, Michael Hudson,
Carl Friedrich Bolz, Antonio Cuni, Anders Chrigstroem, Guido Wesdorp
Maciej Fijalkowski, Alexandre Fayolle

and many others:
http://codespeak.net/pypy/dist/pypy/doc/contributor.html


What is PyPy?
================================

Technically, PyPy is both a Python interpreter implementation and an
advanced compiler, or more precisely a framework for implementing dynamic
languages and generating virtual machines for them.

The framework allows for alternative frontends and for alternative
backends, currently C, LLVM and .NET. For our main target "C", we can
can "mix in" different garbage collectors and threading models,
including micro-threads aka "Stackless". The inherent complexity that
arises from this ambitious approach is mostly kept away from the Python
interpreter implementation, our main frontend.

PyPy is now also a Just-In-Time compiler generator. The translation
framework contains the now-integrated JIT generation technology. This
depends only on a few hints added to the interpreter source and should
be able to cope with the changes to the interpreter and be generally
applicable to other interpreters written using the framework.

Socially, PyPy is a collaborative effort of many individuals working
together in a distributed and sprint-driven way since 2003. PyPy would
not have gotten as far as it has without the coding, feedback and
general support from numerous people.

Formally, many of the current developers were involved in executing an
EU contract with the goal of exploring and researching new approaches
to language and compiler development and software engineering. This
contract's duration is about to end this month (March 2007) and we are
working and preparing the according final review which is scheduled
for May 2007.

For the future, we are in the process of setting up structures to help
maintain conceptual integrity of the project and to discuss and deal
with funding opportunities related to further PyPy sprinting and
developments. See here for results of the discussion so far:

http://codespeak.net/pipermail/pypy-dev/2007q1/003577.html


1.0.0 Feature highlights
==============================


Here is a summary list of key features included in PyPy 1.0:

- The Just-In-Time compiler generator, now capable of generating the
first JIT compiler versions of our Python interpreter:

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

- More Python interpreter optimizations (a CALL_METHOD bytecode, a method
cache, rope-based strings), now running benchmarks at around half of
CPython's speed (without the JIT):

http://codespeak.net/pypy/dist/pypy/doc/interpreter-optimizations.html

- The Python interpreter can be translated to .NET and enables
interactions with the CLR libraries:

http://codespeak.net/pypy/dist/pypy/doc/cli-backend.html
http://codespeak.net/pypy/dist/pypy/doc/clr-module.html

- Aspect Oriented Programming facilities (based on mutating the Abstract
Syntax Tree):

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

http://codespeak.net/pypy/extradoc/...t_Oriented_Programming_in_PyPy-2007-03-22.pdf

- The JavaScript backend has evolved to a point where it can be used to
write AJAX web applications with it. This is still an experimental
technique, though. For demo applications which also showcase various
generated Python and PROLOG interpreters, see:

http://play1.codespeak.net/

- Proxying object spaces and features of our Python interpreter:

- Tainting: a 270-line proxy object space tracking and boxing
sensitive information within an application.

- Transparent proxies: allow the customization of both application and
builtin objects from application level code. Now featuring an
initial support module (tputil.py) for working with transparent
proxies.

For a detailed description and discussion of high level backends and
Python interpreter features, please see our extensive "D12" report:

http://codespeak.net/pypy/extradoc/...ackends_and_Feature_Prototypes-2007-03-22.pdf


Funding partners and organisations
=====================================================

PyPy development and activities happen as an open source project and
with the support of a consortium partially funded by a 28 month
European Union IST research grant for the period from December 2004 to
March 2007. The full partners of that consortium are:

Heinrich-Heine University (Germany), Open End (Sweden)
merlinux GmbH (Germany), tismerysoft GmbH (Germany)
Logilab Paris (France), DFKI GmbH (Germany)
ChangeMaker (Sweden), Impara (Germany)

 

[=?iso-8859-1?q?Luis_M._Gonz=E1lez?=]

==========================================
PyPy 1.0: JIT compilers for free and more
==========================================

Welcome to the PyPy 1.0 release - a milestone integrating the results
of four years of research, engineering, management and sprinting
efforts, concluding the 28 months phase of EU co-funding!

Although still not mature enough for general use, PyPy 1.0 materializes
for the first time the full extent of our original vision:

- A flexible Python interpreter, written in "RPython":

- Mostly unaware of threading, memory and lower-level target platform
aspects.
- Showcasing advanced interpreter features and prototypes.
- Passing core CPython regression tests, translatable to C, LLVM and
.NET.

- An advanced framework to translate such interpreters and programs:

- That performs whole type-inference on RPython programs.
- Can weave in threading, memory and target platform aspects.
- Has low level (C, LLVM) and high level (CLI, Java, JavaScript)
backends.

- A **Just-In-Time Compiler generator** able to **automatically**
enhance the low level versions of our Python interpreter, leading to
run-time machine code that runs algorithmic examples at speeds typical
of JITs!

Previous releases, particularly the 0.99.0 release from February,
already highlighted features of our Python implementation and the
abilities of our translation approach but the **new JIT generator**
clearly marks a major research result and gives weight to our vision
that one can generate efficient interpreter implementations, starting
from a description in a high level language.

We have prepared several entry points to help you get started:

* The main entry point for JIT documentation and status:

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

* The main documentation and getting-started PyPy entry point:

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

* Our online "play1" demos showcasing various Python interpreters,
features (and a new way to program AJAX applications):

http://play1.codespeak.net/

* Our detailed and in-depth Reports about various aspects of the
project:

http://codespeak.net/pypy/dist/pypy/doc/index-report.html

In the next few months we are going to discuss the goals and form of
the next stage of development - now more than ever depending on your
feedback and contributions - and we hope you appreciate PyPy 1.0 as an
interesting basis for greater things to come, as much as we do
ourselves!

have fun,

the PyPy release team,
Samuele Pedroni, Armin Rigo, Holger Krekel, Michael Hudson,
Carl Friedrich Bolz, Antonio Cuni, Anders Chrigstroem, Guido Wesdorp
Maciej Fijalkowski, Alexandre Fayolle

and many others:
http://codespeak.net/pypy/dist/pypy/doc/contributor.html


What is PyPy?
================================

Technically, PyPy is both a Python interpreter implementation and an
advanced compiler, or more precisely a framework for implementing dynamic
languages and generating virtual machines for them.

The framework allows for alternative frontends and for alternative
backends, currently C, LLVM and .NET. For our main target "C", we can
can "mix in" different garbage collectors and threading models,
including micro-threads aka "Stackless". The inherent complexity that
arises from this ambitious approach is mostly kept away from the Python
interpreter implementation, our main frontend.

PyPy is now also a Just-In-Time compiler generator. The translation
framework contains the now-integrated JIT generation technology. This
depends only on a few hints added to the interpreter source and should
be able to cope with the changes to the interpreter and be generally
applicable to other interpreters written using the framework.

Socially, PyPy is a collaborative effort of many individuals working
together in a distributed and sprint-driven way since 2003. PyPy would
not have gotten as far as it has without the coding, feedback and
general support from numerous people.

Formally, many of the current developers were involved in executing an
EU contract with the goal of exploring and researching new approaches
to language and compiler development and software engineering. This
contract's duration is about to end this month (March 2007) and we are
working and preparing the according final review which is scheduled
for May 2007.

For the future, we are in the process of setting up structures to help
maintain conceptual integrity of the project and to discuss and deal
with funding opportunities related to further PyPy sprinting and
developments. See here for results of the discussion so far:

http://codespeak.net/pipermail/pypy-dev/2007q1/003577.html


1.0.0 Feature highlights
==============================


Here is a summary list of key features included in PyPy 1.0:

- The Just-In-Time compiler generator, now capable of generating the
first JIT compiler versions of our Python interpreter:

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

- More Python interpreter optimizations (a CALL_METHOD bytecode, a method
cache, rope-based strings), now running benchmarks at around half of
CPython's speed (without the JIT):

http://codespeak.net/pypy/dist/pypy/doc/interpreter-optimizations.html

- The Python interpreter can be translated to .NET and enables
interactions with the CLR libraries:

http://codespeak.net/pypy/dist/pypy/doc/cli-backend.html
http://codespeak.net/pypy/dist/pypy/doc/clr-module.html

- Aspect Oriented Programming facilities (based on mutating the Abstract
Syntax Tree):

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

http://codespeak.net/pypy/extradoc/...t_Oriented_Programming_in_PyPy-2007-03-22.pdf

- The JavaScript backend has evolved to a point where it can be used to
write AJAX web applications with it. This is still an experimental
technique, though. For demo applications which also showcase various
generated Python and PROLOG interpreters, see:

http://play1.codespeak.net/

- Proxying object spaces and features of our Python interpreter:

- Tainting: a 270-line proxy object space tracking and boxing
sensitive information within an application.

- Transparent proxies: allow the customization of both application and
builtin objects from application level code. Now featuring an
initial support module (tputil.py) for working with transparent
proxies.

For a detailed description and discussion of high level backends and
Python interpreter features, please see our extensive "D12" report:

http://codespeak.net/pypy/extradoc/...ackends_and_Feature_Prototypes-2007-03-22.pdf


Funding partners and organisations
=====================================================

PyPy development and activities happen as an open source project and
with the support of a consortium partially funded by a 28 month
European Union IST research grant for the period from December 2004 to
March 2007. The full partners of that consortium are:

Heinrich-Heine University (Germany), Open End (Sweden)
merlinux GmbH (Germany), tismerysoft GmbH (Germany)
Logilab Paris (France), DFKI GmbH (Germany)
ChangeMaker (Sweden), Impara (Germany)

Congratulations!
I just have a couple of questions:

Attempting to execute pypy-c.exe (precompiled binary for Windows),
raise an error message indicating that it cannot find gc_pypy.dll.
Have you missed something or I'm doing something wrong?

Regarding the jit integration, do you have any rough idea of when will
it speed up arbitrary code, other than integer aritmethic?

Thanks and regards,
Luis

 

[Ben Finney]

==========================================
PyPy 1.0: JIT compilers for free and more
==========================================

Welcome to the PyPy 1.0 release - a milestone integrating the
results of four years of research, engineering, management and
sprinting efforts, concluding the 28 months phase of EU co-funding!

Fabulous! Congratulations to all who contributed to getting PyPy to
this significant milestone.

Here's to all the cool new things people will be doing with PyPy!

 

[Bruno Desthuilliers]

Carl Friedrich Bolz a écrit :

==========================================
PyPy 1.0: JIT compilers for free and more
==========================================

Welcome to the PyPy 1.0 release - a milestone integrating the results
of four years of research, engineering, management and sprinting
efforts

You guys rock !

 

[Carl Friedrich Bolz]

Hi Luis!

>> ==========================================
>> PyPy 1.0: JIT compilers for free and more
>> ==========================================

[snip]
>
>
> Congratulations!

Thanks

> I just have a couple of questions:
>
> Attempting to execute pypy-c.exe (precompiled binary for Windows),
> raise an error message indicating that it cannot find gc_pypy.dll.
> Have you missed something or I'm doing something wrong?

Brain error on our side: the gc_pypy.dll is the dll of the Boehm garbage
collector, which you would need to compile yourself (which makes
precompiled binaries a bit useless ). We updated the zip file, would
you mind checking whether it works better now?

> Regarding the jit integration, do you have any rough idea of when will
> it speed up arbitrary code, other than integer aritmethic?

Relatively soon. The hard bits of that are done, the JIT compiler
generator is in a pretty good shape, we need to apply it to more parts
of the PyPy Python interpreter. There are some non-coding related
reasons why we are not doing it _right_ now: we still need to write some
EU-reports (about the JIT for example) then we will need a while to
recover from the EU project.

Cheers,

Carl Friedrich Bolz

 

[Carl Friedrich Bolz]

Hi Luis!

>> ==========================================
>> PyPy 1.0: JIT compilers for free and more
>> ==========================================

[snip]
>
>
> Congratulations!

Thanks

> I just have a couple of questions:
>
> Attempting to execute pypy-c.exe (precompiled binary for Windows),
> raise an error message indicating that it cannot find gc_pypy.dll.
> Have you missed something or I'm doing something wrong?

Brain error on our side: the gc_pypy.dll is the dll of the Boehm garbage
collector, which you would need to compile yourself (which makes
precompiled binaries a bit useless ). We updated the zip file, would
you mind checking whether it works better now?

> Regarding the jit integration, do you have any rough idea of when will
> it speed up arbitrary code, other than integer aritmethic?

Relatively soon. The hard bits of that are done, the JIT compiler
generator is in a pretty good shape, we need to apply it to more parts
of the PyPy Python interpreter. There are some non-coding related
reasons why we are not doing it _right_ now: we still need to write some
EU-reports (about the JIT for example) then we will need a while to
recover from the EU project.

Cheers,

Carl Friedrich Bolz

 

[Kay Schluehr]

==========================================
PyPy 1.0: JIT compilers for free and more
==========================================

Welcome to the PyPy 1.0 release - a milestone integrating the results
of four years of research, engineering, management and sprinting
efforts, concluding the 28 months phase of EU co-funding!

Although still not mature enough for general use, PyPy 1.0 materializes
for the first time the full extent of our original vision:

- A flexible Python interpreter, written in "RPython":

- Mostly unaware of threading, memory and lower-level target platform
aspects.
- Showcasing advanced interpreter features and prototypes.
- Passing core CPython regression tests, translatable to C, LLVM and
.NET.

- An advanced framework to translate such interpreters and programs:

- That performs whole type-inference on RPython programs.
- Can weave in threading, memory and target platform aspects.
- Has low level (C, LLVM) and high level (CLI, Java, JavaScript)
backends.

- A **Just-In-Time Compiler generator** able to **automatically**
enhance the low level versions of our Python interpreter, leading to
run-time machine code that runs algorithmic examples at speeds typical
of JITs!

Previous releases, particularly the 0.99.0 release from February,
already highlighted features of our Python implementation and the
abilities of our translation approach but the **new JIT generator**
clearly marks a major research result and gives weight to our vision
that one can generate efficient interpreter implementations, starting
from a description in a high level language.

We have prepared several entry points to help you get started:

* The main entry point for JIT documentation and status:

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

* The main documentation and getting-started PyPy entry point:

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

* Our online "play1" demos showcasing various Python interpreters,
features (and a new way to program AJAX applications):

http://play1.codespeak.net/

* Our detailed and in-depth Reports about various aspects of the
project:

http://codespeak.net/pypy/dist/pypy/doc/index-report.html

In the next few months we are going to discuss the goals and form of
the next stage of development - now more than ever depending on your
feedback and contributions - and we hope you appreciate PyPy 1.0 as an
interesting basis for greater things to come, as much as we do
ourselves!

have fun,

the PyPy release team,
Samuele Pedroni, Armin Rigo, Holger Krekel, Michael Hudson,
Carl Friedrich Bolz, Antonio Cuni, Anders Chrigstroem, Guido Wesdorp
Maciej Fijalkowski, Alexandre Fayolle

and many others:
http://codespeak.net/pypy/dist/pypy/doc/contributor.html

What is PyPy?
================================

Technically, PyPy is both a Python interpreter implementation and an
advanced compiler, or more precisely a framework for implementing dynamic
languages and generating virtual machines for them.

The framework allows for alternative frontends and for alternative
backends, currently C, LLVM and .NET. For our main target "C", we can
can "mix in" different garbage collectors and threading models,
including micro-threads aka "Stackless". The inherent complexity that
arises from this ambitious approach is mostly kept away from the Python
interpreter implementation, our main frontend.

PyPy is now also a Just-In-Time compiler generator. The translation
framework contains the now-integrated JIT generation technology. This
depends only on a few hints added to the interpreter source and should
be able to cope with the changes to the interpreter and be generally
applicable to other interpreters written using the framework.

Socially, PyPy is a collaborative effort of many individuals working
together in a distributed and sprint-driven way since 2003. PyPy would
not have gotten as far as it has without the coding, feedback and
general support from numerous people.

Formally, many of the current developers were involved in executing an
EU contract with the goal of exploring and researching new approaches
to language and compiler development and software engineering. This
contract's duration is about to end this month (March 2007) and we are
working and preparing the according final review which is scheduled
for May 2007.

For the future, we are in the process of setting up structures to help
maintain conceptual integrity of the project and to discuss and deal
with funding opportunities related to further PyPy sprinting and
developments. See here for results of the discussion so far:

http://codespeak.net/pipermail/pypy-dev/2007q1/003577.html

1.0.0 Feature highlights
==============================

Here is a summary list of key features included in PyPy 1.0:

- The Just-In-Time compiler generator, now capable of generating the
first JIT compiler versions of our Python interpreter:

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

- More Python interpreter optimizations (a CALL_METHOD bytecode, a method
cache, rope-based strings), now running benchmarks at around half of
CPython's speed (without the JIT):

http://codespeak.net/pypy/dist/pypy/doc/interpreter-optimizations.html

- The Python interpreter can be translated to .NET and enables
interactions with the CLR libraries:

http://codespeak.net/pypy/dist/pypy/doc/cli-backend.html
http://codespeak.net/pypy/dist/pypy/doc/clr-module.html

- Aspect Oriented Programming facilities (based on mutating the Abstract
Syntax Tree):

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

http://codespeak.net/pypy/extradoc/eu-report/D10.1_Aspect_Oriented_Pr...

- The JavaScript backend has evolved to a point where it can be used to
write AJAX web applications with it. This is still an experimental
technique, though. For demo applications which also showcase various
generated Python and PROLOG interpreters, see:

http://play1.codespeak.net/

- Proxying object spaces and features of our Python interpreter:

- Tainting: a 270-line proxy object space tracking and boxing
sensitive information within an application.

- Transparent proxies: allow the customization of both application and
builtin objects from application level code. Now featuring an
initial support module (tputil.py) for working with transparent
proxies.

For a detailed description and discussion of high level backends and
Python interpreter features, please see our extensive "D12" report:

http://codespeak.net/pypy/extradoc/eu-report/D12.1_H-L-Backends_and_F...

Funding partners and organisations
=====================================================

PyPy development and activities happen as an open source project and
with the support of a consortium partially funded by a 28 month
European Union IST research grant for the period from December 2004 to
March 2007. The full partners of that consortium are:

Heinrich-Heine University (Germany), Open End (Sweden)
merlinux GmbH (Germany), tismerysoft GmbH (Germany)
Logilab Paris (France), DFKI GmbH (Germany)
ChangeMaker (Sweden), Impara (Germany)

Nice to read that things are going on. I've still a PyPy 0.7 version
on my notebook. I guess I will upgrade

A somewhat unrelated question. With Py3K Python gets optional type
annotations. Are you already architecting an annotation handler that
can process these annotations? This feature is somewhat competitive to
all the complicated type inference and jitting you have been worked
out so I don't know how it fits well into the current PyPy
architecture?

Ciao,
Kay

 

[Paul Boddie]

A somewhat unrelated question. With Py3K Python gets optional type
annotations.

No, I believe the consensus is that Python 3000 gets optional
annotations which aren't specifically for type information... nudge
nudge, wink wink! That last part is important, because that's also how
many other people have interpreted this particular feature. I seem to
recall that some of the PyPy people weren't interested in static
analysis [1], so I'm skeptical about whether type annotations are
their kind of thing, either. That said, I imagine that the handling of
metadata (including type details) is an element in the way RPython
works, but I also imagine that things get more complicated as such
metadata diverges from plain type information and into arbitrary
"observations" about other aspects of program behaviour.

Still, I'd like to see the PyPy people stick their necks out and
answer your questions. ;-)

Paul

[1] http://codespeak.net/pipermail/pypy-dev/2007q1/003607.html

 

[Paul Boddie]

A somewhat unrelated question. With Py3K Python gets optional type
annotations.

No, I believe the consensus is that Python 3000 gets optional
annotations which aren't specifically for type information... nudge
nudge, wink wink! That last part is important, because that's also how
many other people have interpreted this particular feature. I seem to
recall that some of the PyPy people weren't interested in static
analysis [1], so I'm skeptical about whether type annotations are
their kind of thing, either. That said, I imagine that the handling of
metadata (including type details) is an element in the way RPython
works, but I also imagine that things get more complicated as such
metadata diverges from plain type information and into arbitrary
"observations" about other aspects of program behaviour.

Still, I'd like to see the PyPy people stick their necks out and
answer your questions. ;-)

Paul

[1] http://codespeak.net/pipermail/pypy-dev/2007q1/003607.html

 

[Paul Rubin]

A somewhat unrelated question. With Py3K Python gets optional type
annotations. Are you already architecting an annotation handler that
can process these annotations? This feature is somewhat competitive to
all the complicated type inference and jitting you have been worked
out so I don't know how it fits well into the current PyPy
architecture?

What's the nature of the conflict between annotations and inference?
Haskell for example has both.

 

[Christian Tismer]

Brain error on our side: the gc_pypy.dll is the dll of the Boehm
garbage
collector, which you would need to compile yourself (which makes
precompiled binaries a bit useless ). We updated the zip file,
would
you mind checking whether it works better now?

Why can't we provide a pre-compiled binary?
Is this a license issue?

cheers - chris

 

[Kay Schluehr]

No, I believe the consensus is that Python 3000 gets optional
annotations which aren't specifically for type information... nudge
nudge, wink wink! That last part is important, because that's also how
many other people have interpreted this particular feature.

You are right. The feature is more situated on a syntactical /
interface level. The semantical level has to be specified by
annotation handlers. Among them there will also be those that deal
with type annotations. I have little doubts that one of them will make
it into the stdlib sooner or later and might also influence
compilation.

I seem to
recall that some of the PyPy people weren't interested in static
analysis [1], so I'm skeptical about whether type annotations are
their kind of thing, either.

That's why I asked the question with regard to Py3K style annotations
and not static analysis in Py2X which I consider intractible. The JIT
measures types at runtime and optimizes code using this information
but doing things in this style global optimizations are hardly
tractible as well. My main interest is in an intermediate level, given
type measurements as a byproduct of UTs and code coverage. This
methodology is process-oriented and non interferent.

That said, I imagine that the handling of
metadata (including type details) is an element in the way RPython
works, but I also imagine that things get more complicated as such
metadata diverges from plain type information and into arbitrary
"observations" about other aspects of program behaviour.

RPython is heuristically defined as a subset of Python "static enough
to be translatable to C". So it is actually static analysis that is
done here, not on a local scale but on a simpler sublanguage. It is
not clear to me whether for a sufficiently annotated Py3K program the
inequation RPython != Python still holds?

Still, I'd like to see the PyPy people stick their necks out and
answer your questions. ;-)

Paul

[1]http://codespeak.net/pipermail/pypy-dev/2007q1/003607.html

 

[Carl Friedrich Bolz]

Hi Christian!

Why can't we provide a pre-compiled binary?
Is this a license issue?

We can. That's exactly what we did.

Cheers,

Carl Friedrich Bolz

 

[Carl Friedrich Bolz]

Hi Christian!

Why can't we provide a pre-compiled binary?
Is this a license issue?

We can. That's exactly what we did.

Cheers,

Carl Friedrich Bolz

 

[Kay Schluehr]

What's the nature of the conflict between annotations and inference?
Haskell for example has both.

There is no conflict in Haskell because Haskell has a type system by
default. But Python has none and so one had to define RPython, a
subset of Python *viewed* as static enough to be translatable to C
( RPython is of course as polymorphic as any other Python code and can
be fed with arbitrary types. Only the context makes it special ).
RPython is an approximation to Python on which static type inference
is feasible. RPython is yet defined heuristically and this heuristics
might be changed when RPython can be defined by the power of a type
system defined *formally*. So it might be just a matter of reason to
define a typesystem for interpreter/jit level Python code.

 

[bearophileHUGS]

Kay Schluehr:

RPython is heuristically defined as a subset of Python "static enough
to be translatable to C". So it is actually static analysis that is
done here, not on a local scale but on a simpler sublanguage. It is
not clear to me whether for a sufficiently annotated Py3K program the
inequation RPython != Python still holds?

You may also take a very good look at ShedSkin, it's already able to
compile a decent part of Python, and that part is slowly growing
still.
I'd like to see a comparison of SSPython and RPython (width-wise and
running speed wise too)

Bye,
bearophile

 

[dmitrey]

Hi!
Suppose I have a py-written module.
Is it possible somehow run PyPy on the whole module?
I didn't find it in documentation.
And if yes (or if just run in every module func) what will be after
computer restart?
Should I restart PyPy on the module once again?
And are there any chances/intends for PyPy to be included into Python
core?
Thx, D.

 

[Carl Friedrich Bolz]

Hi!

Hi!
Suppose I have a py-written module.
Is it possible somehow run PyPy on the whole module?
I didn't find it in documentation.
And if yes (or if just run in every module func) what will be after
computer restart?
Should I restart PyPy on the module once again?
And are there any chances/intends for PyPy to be included into Python
core?

PyPy contains a full Python interpreter (which can include a JIT
compiler) and thus replaces the "Python core". PyPy can never really be
integrated into CPython.

Cheers,

Carl Friedrich Bolz

 

[Carl Friedrich Bolz]

Hi!

Hi!
Suppose I have a py-written module.
Is it possible somehow run PyPy on the whole module?
I didn't find it in documentation.
And if yes (or if just run in every module func) what will be after
computer restart?
Should I restart PyPy on the module once again?
And are there any chances/intends for PyPy to be included into Python
core?

PyPy contains a full Python interpreter (which can include a JIT
compiler) and thus replaces the "Python core". PyPy can never really be
integrated into CPython.

Cheers,

Carl Friedrich Bolz

 

[Jarek Zgoda]

Carl Friedrich Bolz napisa³(a):

Welcome to the PyPy 1.0 release - a milestone integrating the results
of four years of research, engineering, management and sprinting
efforts, concluding the 28 months phase of EU co-funding!

So it took 4 yars of work and over 2 yaers of consumption of EU funds,
yeah, great.

Could anybody explain, what this gives to Python and its users? Would
we, eventually, get GIL-free VM, that is capable to consume all
available power of multicore processors? Or, maybe, we'll get something
special, I am unable to dream of? Or is it purely academic project to
create Python VM in Python?