Is a "real" C-Python possible?

[Bruno Desthuilliers]

John Nagle a écrit :

We're ten years into Python, and it's still a naive interpreter.
It's time for a serious optimizing compiler.

Care to provide a less "naive" one ?

(snip usual rant)

I'm surprised that Google management isn't pushing Guido towards
doing something about the performance problem.

Could it be possible they don't see Python's perfs as a "problem" ?

Ok, I don't mean there's no room for improvement here. If you feel like
addressing the problem, you're welcome - in case you didn't notice,
Python is free software.

 

[sturlamolden]

Shed Skin effort. Its author writes "Am I the only one seeing the potential
of an implicitly statically typed Python-like-language that runs at
practically the same speed as C++?"

Don't forget about Pyrex and PyPy's RPython.

By the way, we don't need a hotspot JIT compiler. Lisp has a compiler
invoked by the programmer. We could include optional static typing in
Python, and have an optional static optimizing native compiler for
selected portions of code. That would be easier to implement in the
short run, with JIT-capabilities added later. Pyrex, ShedSkin or
RPython are all good starting points.

 

[Bruno Desthuilliers]

sturlamolden a écrit :
-snip)

We could include optional static typing in
Python,

Please wait - going to get my gun...

 

[Terry Reedy]

| We could include optional static typing in
| Python, and have an optional static optimizing native compiler for
| selected portions of code.

Python 3 will have optional 'type' annotations, where 'type' includes
abstract base classes defined by the interface (methods). So parameters
could be annotated as a Number or Sequence, for instance, which is more
useful often than any particular concrete type. I strongly suspect that
someone will use the annotations for compilation, which others will use
them just for documentation and whatever else.

tjr

 

[Kay Schluehr]

| We could include optional static typing in
| Python, and have an optional static optimizing native compiler for
| selected portions of code.

Python 3 will have optional 'type' annotations, where 'type' includes
abstract base classes defined by the interface (methods). So parameters
could be annotated as a Number or Sequence, for instance, which is more
useful often than any particular concrete type. I strongly suspect that
someone will use the annotations for compilation, which others will use
them just for documentation and whatever else.

tjr

On the danger of hurting some souls, I used to write a type feedback
system a few months ago, which automatically annotates source code
from runtime types. Each run of a program P yields a program TP which
is fully type annotated on covered branches. Since a possible compiler
might need more hints than just relying on the types of function
parameters I changed the syntax of Python slightly for displaying
local type annotations as well. For each Python program P exist
possibly infinitely many programs TP of an extended languages TPython
called "typed snapshots". Each of those snapshots might be translated
using translation machinery a la ShedSkin. From a software engineering
point of view early integration with CPython is required, which means
integration of native code on a per function base and possible
fallback to bytecode interpretation in order to preserve duck-typing.
In the literature such techniques are called "(Offline) Feedback
Driven Optimization", while "Online" techniques refer to JIT
compilation.

When TP is yielded from P the program TP might be used for other
purposes as well because each typed snaphsot suggests static
guarantees in a given type system. This might ease the productive
value of refactoring browsers or other tools used for languages with
type systems. I'm yet not sure about type systems for typed snapshots
but one might interpret them in an existing languages with type
systems.

Kay

 

[sturlamolden]

Python 3 will have optional 'type' annotations, where 'type' includes
abstract base classes defined by the interface (methods). So parameters
could be annotated as a Number or Sequence, for instance, which is more
useful often than any particular concrete type. I strongly suspect that
someone will use the annotations for compilation, which others will use
them just for documentation and whatever else.

I am not sure why a new type annotation syntax was needed Python 3:

def foobar(a: int, b: list) -> int:
#whatever

The same thing has been achieved at least three times before, using
the currently valid syntax:


1. ctypes: function attributes defines types

def foobar(a,b):
#whatever
foobar.argtypes = (int,int)
foobar.restype = int


2. .NET interopability in IronPython: decorators defines types

@accepts(int,int)
@return(int)
def foobar(a,b):
#whatever


3. PyGPU compiler: default argument values defines types (return type
undefined)

def foobar(a = int, b = int):
#whatever

Is is therefore possible to give an optimizing compiler sufficient
information to emit efficient code, even with the current syntax.
Local variables could be inferred by an intelligent type-inference
system like that of Boo. Or one could use attributes or decorators to
attach a type dictionary, {'name': type, ...}, for the type-invariant
local variables. The latter has the advantage of allowing duck-typing
for local variables not present in the static type dict.

Optional static typing is what makes Lips like CMUCL efficient for
numerical code. One could achieve the same with Python already today.

 

[Kay Schluehr]

I am not sure why a new type annotation syntax was needed Python 3:

Because people care about a feature when there is @syntax. Introducing
syntax in Python is also the way of standardization: not everyone
creates his own informal application level annotation syntax when
there is one and only one recommended way of using annotations.

 

[George Sakkis]

Because people care about a feature when there is @syntax.

Good point; the inverse is not true though: time and time again people
cared about some syntax for properties without any change so far. The
result is a handful of different ways to spell out properties; python
2.6 will add yet another variation (http://mail.python.org/pipermail/
python-dev/2007-October/075057.html).

George

 

[Dennis Lee Bieber]

Please wait - going to get my gun...

I'd join you in the line, but I'm not sure /which/ of my firearms
would be sufficient [.17HMR, .30M1 carbine, 7.62NATO, .22LR, 9mm, .357,
..40S&W]... Maybe just the raw pound canisters of Pyrodex and some sort
of fuse <G>
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[Kay Schluehr]

Good point; the inverse is not true though: time and time again people
cared about some syntax for properties without any change so far. The
result is a handful of different ways to spell out properties; python
2.6 will add yet another variation (http://mail.python.org/pipermail/
python-dev/2007-October/075057.html).

George

Yes, I'm aware. Curiously, whenever property syntax is discussed the
discussion loses track and is dragged away by needless side
discussions. Just look at Stephen Bethards withdrawn PEP 359 [1] in
which he finally muses about replacing the class statement by the make
statement. So the PEP ended in "abstract nonsense" instead of
clarifying the point.

[1] http://www.python.org/dev/peps/pep-0359/

I vaguely remember a discussion a few years ago, where someone made
the quite reasonable suggestion of introducing some kind of
thunk_statement:

class A(object):
foo = property:
def fget(self):
return self._foo
def fset(self, value):
self._foo = value

which was translated as follows:

class A(object):
def thunk():
def fget(self):
return self._foo
def fset(self, value):
self._foo = value
return vars()
foo = propery(**thunk())
del thunk

Now people started to consider using the compound statement within
expressions as well because the equal sign is used within method
signatures and call syntax. This lead to a general discussion about
the expr/statement distinction in Python, about multiline lambdas and
functional style programming. These association graphs are almost
predictable.

 

[Carl Friedrich Bolz]

Don't forget about Pyrex and PyPy's RPython.

By the way, we don't need a hotspot JIT compiler. Lisp has a compiler
invoked by the programmer. We could include optional static typing in
Python, and have an optional static optimizing native compiler for
selected portions of code. That would be easier to implement in the
short run, with JIT-capabilities added later. Pyrex, ShedSkin or
RPython are all good starting points.

I just want to stress that adding type hints _won't_ make programs
faster if you use a good specializing JIT compiler. Psyco in particular
would not benefit from type hints at all (even if you changed Psyco take
them into account) and would give you exactly the same speed as without
them.

Cheers,

Carl Friedrich Bolz

 

[Carl Friedrich Bolz]

Don't forget about Pyrex and PyPy's RPython.

By the way, we don't need a hotspot JIT compiler. Lisp has a compiler
invoked by the programmer. We could include optional static typing in
Python, and have an optional static optimizing native compiler for
selected portions of code. That would be easier to implement in the
short run, with JIT-capabilities added later. Pyrex, ShedSkin or
RPython are all good starting points.

I just want to stress that adding type hints _won't_ make programs
faster if you use a good specializing JIT compiler. Psyco in particular
would not benefit from type hints at all (even if you changed Psyco take
them into account) and would give you exactly the same speed as without
them.

Cheers,

Carl Friedrich Bolz

 

[Nicola Larosa (tekNico)]

def fibo(n):
while 1:
try:
return fibo.seq[n]
except AttributeError:
fibo.seq = [0, 1, 1]
except IndexError:
fibo.seq.append( fibo.seq[-2] + fibo.seq[-1] )

I really like this formulation. However, its memory consumption is
proportional to the input number. On a system with one gigabyte of
RAM, it computes the Fibonacci number of 100000 in about four seconds.
However, trying to compute 200000, the machine swaps madly, and the
Python interpreter DOSes the Linux kernel solid, making the system
unresponsive. :-|

If all that cache is not reused, building it may be avoided by
appending the following two lines to the above function:

fibo.seq.pop(0)
n -= 1

With this addition, the above system manages to compute the Fibonacci
number of 1000000 (one million) in about 190 seconds.

This is 6 orders of magnitude faster than Congiano's benchmark. That
is a speed up by a factor of a million.

That's really besides the point. Nice OT, anyway. ;-)

--
Nicola Larosa - http://www.tekNico.net/

AtomPub sits in a very strange place, as it has the potential to
disrupt half a dozen or more industry sectors, such as, Enterprise
Content Management, Blogging, Digital/Desktop Publishing and
Archiving, Mobile Web, EAI/WS-* messaging, Social Networks, Online
Productivity tools.
-- Bill de hÓra, July 2007

 

[George Sakkis]

Curiously, whenever property syntax is discussed the
discussion loses track and is dragged away by needless side
discussions. Just look at Stephen Bethards withdrawn PEP 359 [1] in
which he finally muses about replacing the class statement by the make
statement. So the PEP ended in "abstract nonsense" instead of
clarifying the point.

[1]http://www.python.org/dev/peps/pep-0359/

Ah, the 'make' statement.. I liked (and still do) that PEP, I think it
would have an impact comparable to the decorator syntax sugar, if not
more. Alas, it was too much ahead of its time.. who knows, it might
revive on some 3.x version.

George

 

[sturlamolden]

Ah, the 'make' statement.. I liked (and still do) that PEP, I think it
would have an impact comparable to the decorator syntax sugar, if not
more.

I think it is one step closer to Lisp. I believe that it would be
worth considering adding defmacro statement. Any syntax, including if,
else, for, while, class, lambda, try, except, etc. would be
implemented with defmacros. We would only need a minimalistic syntax,
that would bootstrap a full Python syntax on startup. And as for
speed, we all know how Lisp compares to Python.

 

[Chris Mellon]

I think it is one step closer to Lisp. I believe that it would be
worth considering adding defmacro statement. Any syntax, including if,
else, for, while, class, lambda, try, except, etc. would be
implemented with defmacros. We would only need a minimalistic syntax,
that would bootstrap a full Python syntax on startup. And as for
speed, we all know how Lisp compares to Python.

You say that as if "one step closer to Lisp" is a worthwhile goal.

Python has not become what it is, and achieved the success it has,
because a bunch of people really wanted to use Lisp but didn't think
other people could handle it.

The goal of these sorts of discussions should be to make Python a
better Python. But what happens far too often (especially with
Lispers, but not just them by any means) is that people want to make
Python into a clone or "better" version of whatever other language
they like.

If you're the sort of person who views lisp as the goal that other
languages should aspire to, and I know many of those people exist and
even frequent this list, then you should probably spend your time and
energy on making Lisp a better Lisp and addressing whatever weaknesses
in Lisp have you using Python instead. Trying to fix Lisp (or
whatever) by transforming Python into it isn't going to make you any
happier, and it's just going to derail any discussion of making Python
a better *Python*.

 

[J. Clifford Dyer]

I think it is one step closer to Lisp. I believe that it would be
worth considering adding defmacro statement. Any syntax, including if,
else, for, while, class, lambda, try, except, etc. would be
implemented with defmacros. We would only need a minimalistic syntax,
that would bootstrap a full Python syntax on startup. And as for
speed, we all know how Lisp compares to Python.

Programmable syntax is a very powerful concept. However, python is designed not only to be powerful, but simple, and this change would drastically reduce the simplicity of Python. It would cease to be a good beginner's language. If you want a language with different syntax than python, python has wonderful parsing libraries. Use those instead.

My 2Â.

Cheers,
Cliff

 

[sturlamolden]

Programmable syntax is a very powerful concept.

You don't have to use the programmable syntax just because it's there.
But I do realize it would be a misfeature if it is abused.

Two points:

* Programmable syntax would make it easier to write an efficient
native compiler. The compiler would only need to know about the small
subset of language used for bootstrapping (i.e. any high-level OOP
constructs could emerge from defmacros).

* Numerical extensions like NumPy create a temporary array when
expressions like '(a+b)*(c+d)' is evaluated. This is because the
overloaded operators do not see the whole expression. Programmable
syntax is a remedy for this.

 

[sturlamolden]

Python has not become what it is, and achieved the success it has,
because a bunch of people really wanted to use Lisp but didn't think
other people could handle it.

The goal of these sorts of discussions should be to make Python a
better Python.

I do not want to use Lisp. The syntax is awkward and strange, and does
not fit in my brain. I cannot read Lisp code and get a mental image of
what it does. Readability is what sets Python apart.

But I do think programmable syntax can make Python a better Python,
just as it made Lisp a better Lisp.

 

[Christian Heimes]

> Given that the Python core team has been mostly silent about JIT
compilation and Armin Rigos work in particular which started 5 years
ago ( Psyco will not be promoted towards Python 3.0 and there is no
indication that anyone but Armin would maintain Psyco ) I wonder about
this sudden insight. But maybe you can tell us more when you work on
such stuff for CPython yourself? Given your status in the core Python
team this would have a chance of not being just a loosely coupled
independent project as almost all the interesting stuff that happens
around Python these days.

I don't see an indication that anybody but the creator of Psyco does
understand the code base. *g*

Guido has stated his opinion about optimizations more than once. My own
opinion as core developer (which is quite similar to Guido's opinion) is:

We are happy and glad for every improvement regarding speed, memory
usage or features if and only if:

* The implementation must be clean, well designed, well documented well
written and platform independent / supported on all platforms. Python
runs on machines from mobile phones to large main frames.

* The improvement must NOT hinder or slow down future development at
all cost. If it's so complicated that it might slow down future
development than it's a no go. It's more important to us to have a clean
and understandable code base than to add hundreds of small improvements
which makes debugging a nightmare.

* You are willing to support and fix the improvement for X years where
X is between 4 and INF years.

* The modification must not slow down Python for common uses like a
single threaded, single CPU bound program or small script. This rules
out all existing attempts to remove the GIL from Python since they have
slowed down Python to 50% or less. However Guido said a few months ago
that he would endorse a SMP branch of Python aimed to multi core and
multi threaded apps.

* The code and all its dependencies must be compatible with Python license.

* The code must be written following the C89 standards.

By the way core development is open for everybody. Any patch is
appreciated, starting from fixing a typo in the docs over bug reports,
bug fixes to new features.

Read the PEPs! http://www.python.org/dev/peps/
Subscribe to the mailing lists (I suggest gmane.org)!
Get involved!

Christian