
CPython, the primary implementation of the Python language, has a C API for embedding Python into applications and writing extension modules[1]. The cpython[2] package is a binding to this API. It's not a complete binding yet -- there's a couple areas where I haven't figured out how to represent the C-ish idioms -- so it's not yet possible to do things like implement extension modules[3], run code directly from a file[4], or compile Python strings to code[4]. Hackage can't build docs because it doesn't have the Python development libraries installed, so I've uploaded them to http://ianen.org/haskell/bindings/cpython/api-documentation/. If you encounter any build errors, or have wishes / ideas on which parts of the API to add to the binding, please say so. I will add parts as I figure them out, but wanted to get a working version out ASAP so people can play with it. [1] http://docs.python.org/3.1/c-api/ [2] http://hackage.haskell.org/package/cpython/ [3] http://docs.python.org/3.1/c-api/module.html#initializing-c-modules [4] http://docs.python.org/3.1/c-api/veryhigh.html

John Millikin wrote:
CPython, the primary implementation of the Python language, has a C API for embedding Python into applications and writing extension modules[1]. The cpython[2] package is a binding to this API.
This is a nice thing to have. How does this package compare to the classic MissingPy package? Thanks, Yitz

(sorry for spam; forgot to reply-all)
MissingPy appears to be a set of data types which implement MissingH
classes using the Python library. It has only a minimal binding to
libpython, enough to implement its class instances but not enough for
general-purpose use of libpython.
I wrote this package so I could benchmark Python modules using
Criterion, with an eye towards writing extension modules in Haskell,
so it has many more data types and computations available.
On Sun, Dec 27, 2009 at 14:33, Yitzchak Gale
John Millikin wrote:
CPython, the primary implementation of the Python language, has a C API for embedding Python into applications and writing extension modules[1]. The cpython[2] package is a binding to this API.
This is a nice thing to have.
How does this package compare to the classic MissingPy package?
Thanks, Yitz

John Millikin wrote:
...Python language, has a C API... The cpython[2] package is a binding to this API.
I wrote:
How does this package compare to the classic MissingPy package?
MissingPy appears to be a set of data types which implement MissingH classes using the Python library.
Not exactly. John Goerzen's MissingH and MissingPy libraries together do provide some useful things that are (or were in the past) missing from Haskell. Useful things that already exist in Python and would be a lot of work to re-implement in Haskell are provided in MissingPy via the Haskell binding to the Python API. The rest of the useful things are provided as native Haskell implementations in MissingH. But for me, and probably many others, the most important service provided by MissingPy is the Python API binding itself.
It has only a minimal binding to libpython, enough to implement its class instances but not enough for general-purpose use of libpython.
I'm not sure what you mean by that. Using MissingPy, you can instantiate a Python object of any type, marshall data back and forth between Python and Haskell for the basic built-in Python types and any object built out of them, access any Python module, and call any Python function or method. Most people find those capabilities to be quite good for general-purpose use. What do you feel is missing?
I wrote this package so I could benchmark Python modules using Criterion, with an eye towards writing extension modules in Haskell, so it has many more data types and computations available.
Oh, you want to write Python extension modules in Haskell? Right, MissingPy explicitly does not cover calling Haskell from Python. For accessing Python from Haskell, though, MissingPy has been around for a long time and works well. There may be quite a lot of code around that uses it. Is your API similar? Is there any specific new capability that you are adding? Do you have some compatibility recommendations? One thing you certainly are adding is a more recent version of Python - MissingPy is still at Python 2.5. Also, it is a small annoyance that to use MissingPy's API binding you also have to pull in all of the "missing" things from MissingH and MissingPy and their dependencies. Those aren't used as much these days now that there is so much available from hackage. Thanks, Yitz

On Mon, Dec 28, 2009 at 03:52, Yitzchak Gale
John Millikin wrote:
It has only a minimal binding to libpython, enough to implement its class instances but not enough for general-purpose use of libpython.
I'm not sure what you mean by that. Using MissingPy, you can instantiate a Python object of any type, marshall data back and forth between Python and Haskell for the basic built-in Python types and any object built out of them, access any Python module, and call any Python function or method. Most people find those capabilities to be quite good for general-purpose use. What do you feel is missing?
http://docs.python.org/3.1/c-api/init.html http://docs.python.org/3.1/c-api/reflection.html Most of http://docs.python.org/3.1/c-api/concrete.html Most of http://docs.python.org/3.1/c-api/abstract.html While it is possible to emulate some C API procedures using Python encoded in Haskell, I find the C API more readable. Compare: --------------------------------------------------------- -- emptySet :: IO Set callArgs (getItem (getAttribute (importModule "types") "__builtins__") "set") [] >>= fmap fromJust cast toList [] >>= iterableToSet --------------------------------------------------------- And of course, it's very difficult to do things like create a new interpreter or modify the "sys" module from within a running interpreter.
I wrote this package so I could benchmark Python modules using Criterion, with an eye towards writing extension modules in Haskell, so it has many more data types and computations available.
Oh, you want to write Python extension modules in Haskell? Right, MissingPy explicitly does not cover calling Haskell from Python.
Eventually -- Python 3 improved the module system enough that it should be possible (compared to 2.x, where C-style static memory was essentially required). I'd like to try (for example) implementing the Python "decimal.Decimal" type in terms of Haskell's Ratio.
For accessing Python from Haskell, though, MissingPy has been around for a long time and works well. There may be quite a lot of code around that uses it. Is your API similar? Is there any specific new capability that you are adding? Do you have some compatibility recommendations?
My API's not similar -- one of my goals was to match the C API as closely as is reasonable, with more type safety. According to the reverse dependency-enabled Hackage[1], as of December 24[2] there are no dependencies on MissingPy. In contrast, there are 27 direct and 17 indirect dependencies on MissingH. [1] http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/package/Missing... [2] http://bifunctor.homelinux.net/~roel/hackage/packages/archive/recent.html
participants (2)
-
John Millikin
-
Yitzchak Gale