clpython-devel

clpython-devel@common-lisp.net

46 discussions

[clpython-devel] CLPython on LispWorks
by Willem Broekema 01 Apr '08

01 Apr '08

Dear list members, In the last few days I made CLPython more portable, so that it now runs on LispWorks too! If you have LispWorks, please give it a try and let me know if you encounter any problems. In particular I'd like to hear if the unit test runs fine for you, too. Once that is verified, I'll update the outdated web page with the new status, and call this "CLPython 1.0". Please take these steps: 1. Download CLPython from CVS: cvs -d :pserver:cvspublic@cvspublic.franz.com:/cvs-public login Password: cvspublic cvs -d :pserver:cvspublic@cvspublic.franz.com:/cvs-public checkout clpython 2. Download the test framework "ptester" (the portable version of Allegro's "tester") from http://files.b9.com/ptester/ptester-latest.tar.gz and install that asdf system. 3. Load the :clpython asdf system: (asdf:operate 'asdf:load-op :clpython) 4. Run the CLPython unit tests: (asdf:operate 'asdf:test-op :clpython) The unit test should finish with the message "Errors detected in this test: 5" (which are 5 known issues) and several hundred test successes. Please let me know how this works for you. Also, start up the Python REPL with (clpython:repl) and start typing :-) Cheers, - Willem

1 0

[clpython-devel] inline
by Jones, Eric SPC MIL USA FORSCOM 20 Mar '08

20 Mar '08

This may be a bit of the topic but would support for in-lining be acceptable or even just close interoperability of the two languages. Python and Lisp are similar but some pieces of code are more easily implemented in one or the other. Maybe something like: (LISP CODE) (LISP CODE) :@python python code python code :@PYTHON (LISP CODE) (LISP CODE)

2 1

[clpython-devel] Status?
by Rudolf 16 Jan '08

16 Jan '08

Heya, I just stumbled upon CLPython today. What's the status of it? Is there *any* sort of development going on? What would be a good place, for a CL newbie, to start adding functionality from this list: http://common-lisp.net/project/clpython/status.html Thanks, Rudolf

4 5

[clpython-devel] import fails due to null search paths in *habitat*
by Robert Dodier 05 May '07

05 May '07

Hello, I'm running CL-Python w/ Allegro Express 8.0 on Linux. I find that import fails for anything except stuff in the current working directory. That appears to be because *habitat* has search paths = nil. I tried (setf (habitat-search-paths *habitat*) <stuff>) and that works OK for importing .py files but attempting to import built-in stuff like sys fails. Is there some better way to establish the seach path? Shouldn't the built-in stuff be findable via the default seach paths? Thanks a lot for your help, Robert Dodier

2 3

[clpython-devel] calling Lisp from Python and vice versa
by Robert Dodier 05 May '07

05 May '07

Hello, I am interested in using CL-Python as a front end for Lisp libraries. To this end, I wonder how to call a Lisp function from withing Python. I know you can enter " (foo bar)" to call a Lisp function, but its return value is not known to Python. I'd like to be able to do something like "x = foo(bar)". Couple of questions related to this. How can I reference Lisp variables from Python and vice versa? Can I use import to load a Lisp file? After loading the Lisp file, how do functions and variables in it appear in Lisp --- does the Lisp package name come into play? What about Lisp symbols which contain characters not allowed in Python --- is there a way to escape them? Can a Lisp function return arbitrary Lisp objects, and if so how are those displayed in Python? Thanks a lot to Willem Broekma for inventing and maintaining CL-Python. I think it's a great idea. My immediate interest is to use CL-Python as an interface for the symbolic computation system Maxima which is written in CL. best, Robert Dodier

2 1

[clpython-devel] CLPython for other lisps
by Michel Van den Bergh 04 Feb '07

04 Feb '07

Hi, Is there any hope that CLPython will be ported to other lisps (gcl, clisp, sbcl)? I have been advocating python as a language for maxima. Maxima (maxima.sf.net) is a very powerful GPL'ed computer algebra system that is written in CL. On top on the underlying CL implementation it also supports an algol like programming language ("the maxima language") which however has serious problems (you can check the discussions on the maxima mailing list about this). I think that it would be good to have python available as a second (algol like) language for maxima. Python is a widely known language with well understood semantics. It seems that CLPython would fit the bill but unfortunately the fact that it runs only on one CL implementation makes it impossible to use. For portability maxima has to run on all available CL implementations (and has admirably succeeded in doing so up to now). Best regards, Michel

3 4

[clpython-devel] CVS module renamed to "clpython"
by Willem Broekema 30 Jan '07

30 Jan '07

The CLPython source code is stored in a cvs repository at Franz. Until now the cvs module was named "python". The module has now been renamed to "clpython", the official name of this project. To retrieve the code under the proper module name: cvs -d :pserver:cvspublic@cvspublic.franz.com:/cvs-public login (use password: cvspublic) cvs -d :pserver:cvspublic@cvspublic.franz.com:/cvs-public checkout clpython Of course these instructions are also on http://trac.common-lisp.net/clpython There is more reorganization coming up, in terms of directory structure and packages. I'll describe that when it is submitted, in a few days. Cheers, - Willem

1 0

[clpython-devel] Fwd: Not dead, bold future
by Willem Broekema 17 Dec '06

17 Dec '06

Link to message: http://groups.google.com/group/comp.lang.python/msg/7629a87adac6d0b1 ---------- Forwarded message ---------- From: Willem Broekema <metawilm(a)gmail.com> Date: Dec 13, 2006 8:28 PM Subject: Re: merits of Lisp vs Python To: Paul Rubin wrote: > Does this count as a "children of a lesser Python"? This sounds like a quite derogatory first question. CLPython is not a dead and abandoned project, nor is execution speed its main goal, nor are Python semantics bended anywhere (it can run the Pie-thon benchmark). Sure, some recently introduced language features are missing, but with just a little effort that's solved... Moreover, in Common Lisp source code analysis and manipulation can be expressed easily. CLPython thus provides ample opportunities to analyze type inference or caching schemes. Most of that is unexplored territory, I think. I like the journey so far. > How does clpython implement Python's immutable strings, for example? Normal Python strings are represented by normal Lisp strings. Instances of subclasses of 'str' are represented by CLOS instances. That's for performance reasons. This dual-representation aspect is nicely hidden behind macros, so that even in the code of CLPython itself there's no need to worry, or even know, about it. Why not take a look in the code -- I'll be happy to explain things. - Willem

1 0

[clpython-devel] Fwd: CLPython objects in a Lisp image
by Willem Broekema 17 Dec '06

17 Dec '06

Link to message: http://groups.google.com/group/comp.lang.python/msg/b72788cc5569d778 ---------- Forwarded message ---------- From: metawilm(a)gmail.com <metawilm(a)gmail.com> Date: Dec 16, 2006 12:54 PM Subject: Re: CLPython (was Re: merits of Lisp vs Python) To: Paul Rubin wrote: > metawilm(a)gmail.com writes: > > > a = 'hello' > > > a[0] = 'H' # attempt to change first letter to upper case > > > > As CLPython mirrors Python semantics, this results in a TypeError. The > > internal representation of an immutable Python string is a mutable Lisp > > string, but there is no way you can actually modify it from within CLPython. > > How do you manage that? The compiler can't check. Is there some kind > of special dispatch on the assignment statement instead of turning it > into a setf? Indeed, the assignment of subitems is dynamically dispatched, and always goes via __setitem__ methods, as specified in the language. The __setitem__ methods for strings and tuples raise exceptions. The ones for lists and vectors could be translated into a simple (setf (aref ..) ..) and (setf (nth ..) ..), unless the index is actually a slice and actually a subsequence must be replaced. Now, the above description using __setitem__ methods is how it apparently works, as observed from the outside. Internally there is a generic function (setf py-subs) that does the work itself, skipping the lookup and calling of __setitem__, if the object is a vector or dict. (The user can call x.__setitem__ explicitly, so that method must exist internally.) Maybe you were thinking that CLPython, given Python code, outputs a big pile of self-contained equivalent Lisp code that can be run independently, and then CLPython is finished. Instead, only a small amount of Lisp code is generated, but that code can only be run when the CLPython environment is loaded. The generated code refers to that environment, e.g. s[0] = 'x' is translated into a call to (setf (py-subs ..) ..), and function (setf py-subs) is part of the CLPython environment that must be loaded at run-time. If you compile a Python function, the result is a (mostly) normal Lisp function - its origin from the Python world does not really matter. Also, all Python data structures are first-class Lisp data. Thus CLPython objects live happily together with "normal" Lisp objects in the same image. And now we arrive at the most exciting part: other Lisp libraries can be loaded in the same image, and we can create connections. Like, after loading CLIM and defining how CLPython objects should be presented, we should get a Python interpreter where classes are displayed graphically and where you can inspect and modify them by mouse. Imagine that you have interactively added a method to a class by dragging a function to a class, then being able to right-click and select "write method", which will write the definition of the method in the right place in the class definition source code in your Climacs (CLIM-based Emacs) buffer. That's the kind of features I have in mind, and the best thing is that conceptually a lot of the work consists of connecting dots that already out there. But as there are so many of them, a few extra pencils would be quite welcome <wink> - Willem

1 0

[clpython-devel] Fwd: Choice of Common Lisp
by Willem Broekema 17 Dec '06

17 Dec '06

Link to message: http://groups.google.com/group/comp.lang.python/msg/fbfdc12acddc0f3f ---------- Forwarded message ---------- From: metawilm(a)gmail.com <metawilm(a)gmail.com> Date: Dec 15, 2006 8:23 PM Subject: Re: CLPython (was Re: merits of Lisp vs Python) To: Paul Rubin wrote: > I thought it was of some interest though I'm a little surprise by the > choice of CL rather than Scheme as a target. In many aspects Python is a subset of CL. In CLPython, exceptions are Lisp conditions with a custom metaclass (strictly spoken not portable CL), Python (meta)classes are CLOS classes, methods are implemented using hashtables and functions and CLOS generic functions, strings and numbers have direct equivalents, hash tables implement dicts, Python functions are funcallable CLOS instances, tuples and lists are Lisp lists and vectors, generators are closures. Thus a great part of implementing CLPython consisted of connecting already existing dots. I found that quite amazing. > I'm still not sure about the mapping of Python strings to Lisp strings. > What happens with the following in CLPython? > > a = 'hello' > a[0] = 'H' # attempt to change first letter to upper case As CLPython mirrors Python semantics, this results in a TypeError. The internal representation of an immutable Python string is a mutable Lisp string, but there is no way you can actually modify it from within CLPython. Now in some cases modifying strings is dangerous (e.g. when stored in an instance dict to represent an attribute), but in other cases it can be completely safe. And modifying strings is a normal Lisp feature, so it sounds strange to disallow it at all times. Maybe there should be a way for the user to declare that he knows what he is doing, and does not want the Python implementation to be "crippled" w.r.t. the host language. Normally you start the CLPython interpreter using (repl); maybe something like this would allow dangerous statements: (let ((*strict-python-semantics* nil)) (repl)) Oh, and there is actually one way to modify Python strings in the interpreter, namely using Lisp commands: PYTHON(12): (repl) [CLPython -- type `:q' to quit, `:help' for help] >>> s = "abc" 'abc' >>> (setf (aref _ 0) #\x) #\x >>> s 'xbc' >>> type(s) #<class PY-STRING @ #x10575342> >>> type(s) == str 1 >>> s 'xbc' >>> (inspect _) A NEW simple-string (3) "xbc" @ #x11548f6a 0-> The character #\x [#x0078] 1-> The character #\b [#x0062] 2-> The character #\c [#x0063] [1i] PYTHON(13): :ptl >>>

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

clpython-devel