Paul Rubin wrote: > [EMAIL PROTECTED] 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 -- http://mail.python.org/mailman/listinfo/python-list
