Is a "real" C-Python possible?

[Jack]

I understand that the standard Python distribution is considered
the C-Python. Howerver, the current C-Python is really a combination
of C and Python implementation. There are about 2000 Python files
included in the Windows version of Python distribution. I'm not sure
how much of the C-Python is implemented in C but I think the more
modules implemented in C, the better performance and lower memory
footprint it will get.

I wonder if it's possible to have a Python that's completely (or at
least for the most part) implemented in C, just like PHP - I think
this is where PHP gets its performance advantage. Or maybe I'm wrong
because the core modules that matter are already in C and those Python
files are really a think wrapper. Anyhow, if would be ideal if Python
has performance similar to Java, with both being interpreted languages.

Jack

[Carl Friedrich Bolz]

sturlamolden wrote:

On 11 Des, 20:25, John Nagle <na...@animats. comwrote:

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

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]

sturlamolden wrote:

On 11 Des, 20:25, John Nagle <na...@animats. comwrote:

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

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

[George Sakkis]

On Dec 12, 4:09 am, Kay Schluehr <kay.schlu...@g mx.netwrote:

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]

On 12 Des, 12:56, George Sakkis <george.sak...@ gmail.comwrote:

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]

On Dec 12, 2007 8:36 AM, sturlamolden <st**********@y ahoo.nowrote:

On 12 Des, 12:56, George Sakkis <george.sak...@ gmail.comwrote:

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.

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]

On Wed, Dec 12, 2007 at 06:36:49AM -0800, sturlamolden wrote regarding Re: Is a "real" C-Python possible?:

>
On 12 Des, 12:56, George Sakkis <george.sak...@ gmail.comwrote:

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.

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]

On 12 Des, 17:44, "J. Clifford Dyer" <[e-mail] tar.orgwrote:

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]

On 12 Des, 17:00, "Chris Mellon" <arka...@gmail. comwrote:

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.

[Paul Rudin]

Christian Heimes <li***@cheimes. dewrites:

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

... platform independent / supported on all platforms. Python runs
on machines from mobile phones to large main frames.

JOOI - there are things in the standard library that are not supported
on all platforms. Why would that be a basis for excluding some
psyco-like package?

[Christian Heimes]

Kay Schluehr wrote:

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

Python 2.6 and 3.0 have a more Pythonic way for the problem:

class A(object):
@property
def foo(self):
return self._foo

@foo.setter
def foo(self, value)
self._foo = value

@foo.deletter
def foo(self)
del self._foo

class B(A):
# one can even overwrite the getter in a subclass
@foo.getter
def foo(self):
return self._foo * 2

Christian