ANN: CLPython
Willem Broekema
CLPython is an implementation of Python in Common Lisp. At
http://common-lisp.net/project/clpython you can read more, download the
source (released under LLGPL), and subscribe to the "develop" or
"announce" mailing list.
For now the major functionality offered is a read-eval-print loop (in
Python terms an "interpreter") which understands a large part of the
Python language. And currently only Allegro CL 8.0 is supported. But
hey, it's a start. Portable CL, speed improvements, full Python
language (and modules) support, and Lisp-Python bridging are the next
targets.
Happy hacking!
- Willem
Julian Stecklina
Seems to work without problems on ACL 7.0. Very good work! As a
sidenote: it would be nice, if it had a proper ASDF definition instead
of the load.cl kludge. And don't wait too long with the CVS repo. :)
Regards,
--
Julian Stecklina
Being really good at C++ is like being really good at using rocks to
sharpen sticks. - Thant Tessman
Karstens Rage
I don't get this. Why would anyone want this or care?
k
--
http://karstensrage.blogspot.com/
Rants and raves about pretty much anything I happen to be thinking about
Pascal Bourguignon
> Willem Broekema wrote:
>> Hey,
>> CLPython is an implementation of Python in Common Lisp. At
>> http://common-lisp.net/project/clpython you can read more, download the
>> source (released under LLGPL), and subscribe to the "develop" or
>> "announce" mailing list.
>> For now the major functionality offered is a read-eval-print loop
>> (in
>> Python terms an "interpreter") which understands a large part of the
>> Python language. And currently only Allegro CL 8.0 is supported. But
>> hey, it's a start. Portable CL, speed improvements, full Python
>> language (and modules) support, and Lisp-Python bridging are the next
>> targets.
>> Happy hacking!
>> - Willem
>>
>
> I don't get this. Why would anyone want this or care?
So for example, an admin could use python code from his CL scripts.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Small brave carnivores
Kill pine cones and mosquitoes
Fear vacuum cleaner
Alex Mizrahi
(you :wrote :on '(Tue, 04 Jul 2006 23:04:21 -0700))
(
KR> I don't get this. Why would anyone want this or care?
if they do "(and modules) support, and Lisp-Python bridging " that would be
great, there's lot of python modules having functionality not available in
CL
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
Julian Stecklina
> (message (Hello 'Karstens)
> (you :wrote :on '(Tue, 04 Jul 2006 23:04:21 -0700))
> (
>
> KR> I don't get this. Why would anyone want this or care?
>
> if they do "(and modules) support, and Lisp-Python bridging " that would be
> great, there's lot of python modules having functionality not available in
> CL
The ones providing C bindings would be useless, as they won't work. What
Python library would be useful in particular? (Just curious.)
mrcsp...@gmail.com
Because. I think that is a good enough reason. You don't speak for me
at least.
Kaz Kylheku
> I don't get this. Why would anyone want this or care?
Who would want a Python interface to Lisp?
How about Python users who are looking to port their skills to a mature
development platform which has things like dynamic compilation to
native code and real garbage collection?
:)
Ken Tilton
Willem Broekema wrote:
> Hey,
>
> CLPython is an implementation of Python in Common Lisp.
Congrats on the release. Do Python programs run as native-compiled code
or interpreted by a CL Python interpreter?
> At
> http://common-lisp.net/project/clpython you can read more,
> download the
> source (released under LLGPL), and subscribe to the "develop" or
> "announce" mailing list.
>
> For now the major functionality offered is a read-eval-print loop (in
> Python terms an "interpreter") which understands a large part of the
> Python language. And currently only Allegro CL 8.0 is supported. But
> hey, it's a start. Portable CL, speed improvements, full Python
> language (and modules) support, and Lisp-Python bridging are the next
> targets.
Just make sure you can run this code:
http://pyworks.org/svn/pycells/
:)
ken
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton
Karstens Rage wrote:
> Willem Broekema wrote:
>
>> Hey,
>>
>> CLPython is an implementation of Python in Common Lisp. At
>> http://common-lisp.net/project/clpython you can read more, download the
>> source (released under LLGPL), and subscribe to the "develop" or
>> "announce" mailing list.
>>
>> For now the major functionality offered is a read-eval-print loop (in
>> Python terms an "interpreter") which understands a large part of the
>> Python language. And currently only Allegro CL 8.0 is supported. But
>> hey, it's a start. Portable CL, speed improvements, full Python
>> language (and modules) support, and Lisp-Python bridging are the next
>> targets.
>>
>> Happy hacking!
>>
>> - Willem
>>
>
> I don't get this. Why would anyone want this...
A pythonista can now have seamless access (well, when CLPython gets that
far) to a much more powerful language and all those CL libraries.
Lispniks get that much closer to world domination, the derivative wins
being we then get to (a) be even smuggier and (b) use Lisp at work.
Karstens Rage
>
> Because. I think that is a good enough reason. You don't speak for me
> at least.
>
I didn't mean to speak for you but 'because' doesn't do it for me.
Having Python bindings to Lisp and vice versa makes sense but all the
announcement said was an implementation of Python in Lisp. So what? Ok,
the idea that you can have CL scripts that call Python might be
something but what can you do in Python (with this implementation) that
you can't do in CL? I'm not really asking for an answer.
I totally understand the ability to call C, or any language for that
matter from CL and vice versa but I don't get reimplementing the spokes
of the wheel in another language for the sake of it or "because."
k
Ken Tilton
It may be the same reason Norvig ported PAIP to Python and I encouraged
a PyCells project. I mean, I am not disagreeing, I just think the social
dynamics are not being considered.
Notice also the mention of support from Franz and the fact that it is
ACL8-only. Hey, Franz tech support is great, but you do not see me
citing Franz on the Cells page. Those sneaky rascals were also behind PCL.
My2?: empire building.
kenny
OMouse
Ken Tilton wrote:
> A pythonista can now have seamless access (well, when CLPython gets that
> far) to a much more powerful language and all those CL libraries.
Uh...There are useful and powerful CL libraries?
Ken Tilton
You must be new around here. That was a joke. If anyone posts a link to
c-l.net, ignore them, it's all garbage.
kenny
Tim X
As I understand it, its not an implementation of python in CL, but a
framework for calling python libraries from within CL - the objective
I believe is to make python libraries available in CL - rather than
re-invent a library which already exists, borrow the functionality
instead.
On one hand, given the large selection of python libraries, this may
be a good thing. On the other, if it overly constrains what you can do
or how you use CL, it may not be so good (i.e. lowest common
denominator etc).
Tim
--
tcross (at) rapttech dot com dot au
Willem Broekema
Ken Tilton wrote:
> Congrats on the release. Do Python programs run as native-compiled code
> or interpreted by a CL Python interpreter?
Thanks. It's all compiled to native code. A reason is that information
about e.g. variable scopes is stored in "environments" using a private
declaration type (declare (pydecl ...) ..) and those declarations are
only taken into account if the code is compiled, therefore compilation
is required before execution.
And of course compilation is for efficiency. Besides the normal work
the compiler does, there are compiler macros that save allocations of
temporary intermediate objects (e.g. bound methods) and inline of
common cases, so execution time is reduced.
Currently the execution speed varies from being on par with CPython for
numerical stuff (e.g. file b2.py from parrotbench, which in fact means
Allegro's and Python's arithmetic are about equally fast), to being up
to 3 or 4 times slower for highly "dynamic" code (in particular lots of
attribute and methods lookups, like in file b0.py). All in all not bad,
but of course we'd like to improve efficiency.
> Just make sure you can run this code:
>
> http://pyworks.org/svn/pycells/
Sure, if you promise not to use C modules...
- Willem
Pisin Bootvong
Ken Tilton เขียน:
It looks like you got the saying backward.
CL is great when you have to solve uncommon problem domain, where
implementing your own library is neccessary. However, most user of
Python are solving more generalize problem domain, DB, Business,
Reporting, etc.. In those area the presence of available library is
advantage.
>From the point of view of a Pythonista:
- The advantage of Common Lisp is that the language itself is so
powerful. It can express algorithm, etc. clearly.
- The disadvantage of Common Lisp is that it lacks wide range of
library. It has been said thing are getting better, but that still
means there are less libraries in CL than in Python. The existence of a
library is not all that count. You must also take into account the
number of maintainer in a project -- I wouldn't want the library I use
to dies with its only maintain. Size of library user base, which mean
availability of documentation/tutorial. So I think it's clear that
library is the disadvantage in CL side.
>From the point of view of CLers:
- The advantage of Python is the large amount of well maintain library
to choose from. Many of useful Python library are binding libraries.
Although all library can be reimplemented in CL, CL community is not
big enough to have man power to do it.
- The disadvantage of Python is that the language is not powerful
enough for programming hard complex problem.
So by using Python on top of CL runtime. You get to write a less
powerful language with on run time that has less support for library.
Seems like a worst of both world.
When you step down in the language expressiveness, you would expect to
gain low level advantage. By writing python on CL, you only get to give
up expressiveness without benefit of low level advantage since you are
still in CL world.
I can understand the intention of CLPython author to help CL situation
of lacks of library. If a Python library to use is written in pure
Python then CL can load it on using CLPython and be able to use those
useful library.
But if you thik the intention was to get Pythonista to move on to Lisp
runtime, where there is less binding library for them. I think it is
not gonna work.
Leonid Slobodov
> Sure, if you promise not to use C modules...
>
> - Willem
Couldn't this restriction be fixed by using CFFI?
I mean that you could use the same interface from modules
(aka dynamic libraries) CPython uses and just
implement the module loading in a different way.
My (very) limited knowledge of Python and specifically
the C API suggests that this is doable (if
your CLPython supports modules at all).
The implementation of functions would still be in C,
but this shouldn't matter with CFFI.
Leonid Slobodov
> Couldn't this restriction be fixed by using CFFI?
> I mean that you could use the same interface from modules
> (aka dynamic libraries) CPython uses and just
> implement the module loading in a different way.
> My (very) limited knowledge of Python and specifically
> the C API suggests that this is doable (if
> your CLPython supports modules at all).
> The implementation of functions would still be in C,
> but this shouldn't matter with CFFI.
Sorry, forget this nonsense. I just checked the docs and it
would be highly complicated to do this (probably something
like building some stub C API version that can be used by CLPython).
On the positive side, the modules may be written in CL! Yay! :-)
Marcus Breiing
> CL is great when you have to solve uncommon problem domain
[...]
> So by using Python on top of CL runtime. You get to write a less
> powerful language with on run time that has less support for
> library. Seems like a worst of both world.
Working in even the most deliciously uncommon problem domain, the
final product may still have to contain anywhere between 10 to 90
percent of boring "grunt work" kind of code.
So I guess something like CLPython could add a design choice: Have
your wizards design and code the uncommon bits using CL, then hire a
cheap Pack of Python Programmers for the remaing boring bits, building
on top of the wizard's work. You'd still be able to keep and deliver
everything in a single (CL) image, which may be convenient. I'd agree
that this would be a more of a big-corporate thing, not something the
lone or small-team wizard would crave.
--
Marcus Breiing
Rob Thorpe
> Karstens Rage wrote:
> > Willem Broekema wrote:
> >
> >> Hey,
> >>
> >> CLPython is an implementation of Python in Common Lisp. At
> >> http://common-lisp.net/project/clpython you can read more, download the
> >> source (released under LLGPL), and subscribe to the "develop" or
> >> "announce" mailing list.
> >>
> >> For now the major functionality offered is a read-eval-print loop (in
> >> Python terms an "interpreter") which understands a large part of the
> >> Python language. And currently only Allegro CL 8.0 is supported. But
> >> hey, it's a start. Portable CL, speed improvements, full Python
> >> language (and modules) support, and Lisp-Python bridging are the next
> >> targets.
> >>
> >> Happy hacking!
> >>
> >> - Willem
> >>
> >
> > I don't get this. Why would anyone want this...
>
> A pythonista can now have seamless access (well, when CLPython gets that
> far) to a much more powerful language and all those CL libraries.
And possibly allow users to script programs in Python, which they may
find useful.
> Lispniks get that much closer to world domination, the derivative wins
> being we then get to (a) be even smuggier and (b) use Lisp at work.
If CLPython is embarrassingly simple compared to the C implementation
of Python that in itself would be a useful demonstration of Lisp.