PyQL : a new set of Python wrappers for QuantLib

Hi folks,

We are happy to announce the release of PyQL [1], a new set of Python wrappers for QuantLib.

The project is available here :

* URL:
* License: BSD license.
* Authors: Didrik Pinte, Enthought and Patrick Henaff, IAE Paris.

Why another set of Python wrappers for QuantLib?

The SWIG wrappers provide a very good coverage of the library but have
a number of pain points:

  •   few Pythonic optimisation in the syntax: the code a user must writeon the Python side looks like the C++ version
  • no docstring or function signature available on the Python side
  • complex debugging and complex customization of the wrappers
  • monolithic build process
  • complete loss of the C++ code organisation with a flat namespace in Python
  • SWIG typemaps development is not that fun

For those reasons and to have the ability to expose some of the
QuantLib internals that could be very useful on the Python side, we
chosed another road. PyQL is build on top of Cython and creates a thin
Pythonic layer on top of QuantLib. It allows a tight control on the
wrapping and provides higher level Python integration.


  1. Integration with standard datatypes (like datetime objects) and numpy arrays
  2. Simplifed API on the Python side (e.g. usage of Handles completely hidden from the user)
  3. Support full docstring and expose detailed function signatures to Python
  4. Code organised in subpackages to provide a decent namespace, very close to the C++ code organisation
  5. Easy extendibility thanks to Cython and shorter build time when adding new functionnalities
  6. Sphinx documentation

It supports QuantLib >= 1.1 and currently builds very nicely on MacOSX
and Linux. The Windows builds will be there soon. Regarding the build
process, make sure you read the build instruction!
(Cython 0.15 needs a simple patch available in the repo)

The library comes with a decent test suite and many examples: from the
very basic option valuation to more complex heston model calibration
within an IPython notebook.

For more details, take a look at the code, contact the authors, or
discuss on the list!

We are looking forward questions, comments, contributions.

[1] The name is still subject to modification as PyQL is already used
by other projects unrelated to QuantLib. Suggestions are welcome!

About these ads

28 Responses to PyQL : a new set of Python wrappers for QuantLib

  1. I was scrolling down do leave PyQuant as a suggestion, too! So I’ll officially be the second vote for that name.

    I have zero experience with Cython, but I’ve used QuantLib and the SWIG Python bindings a good bit…you’re list of shortcomings is on point, if not generously brief. Two questions, though, about your project:
    1) I’ve heard good things about Cython and performance…have you benchmarked any of the converted projects against the SWIG bindings?
    2) I assume your objective is to preserve the structure of QuantLib, rather than add to it…is that accurate?

    • dpinte says:

      I note the second PyQuant vote then ;-)

      Regarding your questions :

      1) I have made a very miminmal benchmark just on the Date object wrapped with SWIG and Cython. The Cython wrappers are 4 to 5 times faster than the SWIG wrappers. The test is in the documentation.

      2) For the low level part, yes. We try to stay as close as possible to the QuantLib C++ code structure. We plan a higher level layer that will be much more Pythonic and much closer to many of the day to day applications. That layer will add a number of functions on top of the existing QuantLib structure.

      • Ramanuj Lal says:

        Could you kindly guide me on how to install this? There is no documentation at all, if there is I can’t find it. I installed quantlib, visual studio 9.0. I have python and cython setup in my system.

        I am on Windows 7. I downloaded the repo from the github and gave the command

        python install

        I got the following output:

        C:\Python27\lib\distutils\ UserWarning: Unknown Extension options: ‘pyrex_directives’
        running install
        running bdist_egg
        running egg_info
        writing requirements to quantlib.egg-info\requires.txt
        writing quantlib.egg-info\PKG-INFO
        writing top-level names to quantlib.egg-info\top_level.txt
        writing dependency_links to quantlib.egg-info\dependency_links.txt
        reading manifest file ‘quantlib.egg-info\SOURCES.txt’
        writing manifest file ‘quantlib.egg-info\SOURCES.txt’
        installing library code to build\bdist.win32\egg
        running install_lib
        running build_py
        running build_ext
        building ‘*’ extension
        c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\cl.exe /c /nologo /Ox /MD /W3 /GS- /DNDEBUG -DHAVE_CONFIG_H -D__WIN32__ -DWIN32 -DNDEBUG -D_WINDOWS
        -I./cpp_layer -IC:\Python27\include -IC:\Python27\PC /Tcquantlib/*.c /Fobuild\temp.win32-2.7\Release\quantlib/*.obj /GR /FD /Zm250 /EHsc
        c1 : fatal error C1083: Cannot open source file: ‘quantlib/*.c’: Invalid argument
        error: command ‘”c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\cl.exe”‘ failed with exit status 2

        Sorry to dump this over here, but I had no idea where else!

      • dpinte says:

        Building on Windows is on our todo list. Do you have QuantLib properly built? What is your file?

        I would suggest we discuss that on the issue tracker of the project: . Create a new issue and we will try to solve it. It is pretty important for the project

  2. Ramanuj Lal says:

    This looks like exactly what I need. Great effort. Where can I find documentation/tutorials for this project?

    • dpinte says:

      The “documentation” and “tutorial” are within the doc directory on github. It is pretty sparse so far. You have to build them using sphinx.

  3. Gabriel says:

    Managed to install this on my Snow Leopard. Works great, thank you very much for your work guys !

  4. Simon Shakeshaft says:

    Just installed under Windows 7, Python 2.7.3 [32 bit] and Visual Studio 2008. Needed to make a few minor changes to Happy to share the details if this is still an open issue.

    • Mark Bean says:

      I would love to know what you needed to change to get the install to work. I would like to try PyQL but will be working on Windows 7, Python 2.7.3 64bit. Visual Studio 2010. Thanks in advance.

      • dpinte says:

        Simon has the same issue as all the others ;-)
        Getting the wrappers to build is not too complex. The issue is that the Setting singleton does not seem to be shared by the different pyd files … Still investigating but not much bandwidth currently.

      • Mark Bean says:

        Sorry to ask what maybe a silly question, but does this mean that PyQL is completely unusable on Windows or is it just a subset of the functionality that doesn’t work at present?

      • Mark Bean says:

        Just spent some time working my way through QuantLib and I now understand at least some of the problems that Setting not being a singleton will cause.

      • Simon Shakeshaft says:

        Just to add to what Didrik said, my understanding is that each .pyd [.dll under Windows] is compiled with all its dependent objects, so for example the Settings singleton class will be compiled into bonds.pyd as well as settings.pyd, but any code in bonds.pyd will access Settings in its own compilation unit.

        It is possible to work around this by creating a custom build step for bonds and including Settings.pyx etc [I’d need to check my repo for the details if you are interested]. You would then need to access Settings in this context.

        It’s likely that this issue may exist in other QuantLib classes that derive from the singleton class, or depend on other static data members.

        The changes I made to were to make the defines = [ ('HAVE_CONFIG_H', None)] statement not part of the win32 build, and I also commented out the pyrex_directives = CYTHON_DIRECTIVES as I found these were not recognised in my build config.

        Also I see you intend to build under Visual Studio 2010 – there are possibly some issues with this as Python itself is compiled under VS2008. It may be possible to recompile under VS2010, but I don’t think it’s a supported config e.g.

      • dpinte says:

        Sounds like the pybg guys have found a way to solve the issue. The dependant cpp/hpp file need to be compiled directly with VS and not through distutils as a dependant file from the pyx extension. Will try to test this asap.

      • sriram says:

        Mark or Simon, would you mind assisting me to get this working? I have a similar setup to yours, but use a later version of Visual Studio. Your help is greatly appreciated…

        Sorry for the post below, meant to place it within this thread.

      • Simon Shakeshaft says:

        Hi Sriram, there will be some issues using a later version of Visual Studio since the Python dist. is compiled with VC9, so there will probably be run time library issues. see It may be possible to recompile the Python source under Visual Studio 2010 – see Which version of Visual Studio are you targeting?

      • dpinte says:

        Hey Simon, you can bypass distutils by faking a VS90 install. Just do update the environment variable on your command line like this (making the assumption you have the VS100COMNTOOLS environment variable set):

        set VS90COMNTOOLS = %VS100COMNTOOLS%

  5. sriram says:

    Simon, would you mind helping out with how to get this working under Windows 7? The only difference between my setup and yours is that I use a later version of Visual Studio. Looking forward to your reply.

  6. stas says:

    I actually compiled the thing on Windows, using x64 since I am running on 64-bit python 2.7. Using the Windows 7 SDK combined with Visual C++ 9.0, via command-line, this seems to work pretty cleanly. Now for the problem that I see:

    It doesn’t look like there is support for polymorphism. The C++ QL has at least 6 different ways to initiate a DepositRateHelper, depending on how and which information you are supplying. On the other hand in PyQl it seems that only one of them exists – precisely the one declared in rate_helpers.pyx. Trying to invoke any other version results in a type error or a complete crash of python.

    def __init__(self, Rate quote, Period tenor=None, Natural fixing_days=0,
    Calendar calendar=None, int convention=ModifiedFollowing,
    end_of_month=True, DayCounter deposit_day_counter=None,
    IborIndex index=None

    I do not deeply understand what is going on with the cython here, so what I am missing here?


    • dpinte says:

      Hi stas, good to hear you can compile it properly. Could you run the test suite and report the results ? There is a long standing bug with the QuantLib::Settings singleton that should make some of that fail under windows.

      For the DepositRateHelper constructor, we currently expose only one. The typical approach there is to create some factory class methods to support the other constructors we need to expose. If you have crashes, please report on the pyql bug tracker with some reproducible code (see )


      • stas says:

        Thanks for the reply. I think I understand things better now. I did not notice the test suite, so ran it now. It show that some things don’t work as expected, so I’ll have to dig and figure out what exactly is going on.

        Following tests produce errors: (fail 2, skip 1) (fail 1) (fail 1) (fail 1) (fail 3)

        I am going to be messing around with this more, so instead of putting up the raw output of failed tests I’ll see if I can figure out what is breaking them first and drop you a better description.

      • Sriram says:

        I am writing in this forum after a long time and wanted to update you on some success and challenge. First, I am able to compile quantlib on an AMD 64 bit platform with Python 2.7 using Visual Studio 2012. I’m also able to successfully run in the pyql distribution. I’d be happy to assist anyone who needs help here.

        My interest is in pricing credit default swaps, and I have challenges. I am able to run CDS.exe that comes with the quantlib Visual Studio solution and see reasonable outputs. However, when I run the that comes with pyql, I don’t get meaningful results.

        Similar to stas’s experience below, when I run various components of the test suite, I get failures. the, however, returns an OK status.

        Any thoughts or suggestions? I provide the output of below. I note that within the body of that script is commented some C++ code. It seems that you might be aware of some problems in accessing values from hazard_rate_structure. The 0 values for the default and coupon legs are consistent with 0-valued hazard rates (or null pointers, perhaps).


        PS C:\temp\pyql-master\examples> python
        Some survival probability values:
        1Y survival probability: 97.039689%
        expected: 97.040000%
        2Y survival probability: 99.950750%
        expected: 94.180000%
        Repricing of quoted CDSs employed for calibration:
        3M fair spread: 0.0
        NPV: 0.0
        default leg: 0.0
        coupon leg: 0.0
        6M fair spread: 0.0
        NPV: 0.0
        default leg: 0.0
        coupon leg: 0.0
        1Y fair spread: 0.0
        NPV: 0.0
        default leg: 0.0
        coupon leg: 0.0
        2Y fair spread: 0.0
        NPV: 0.0
        default leg: 0.0
        coupon leg: 0.0

      • Sriram says:

        Reporting back some additional findings here… as I mentioned below, I am not getting correct results when I run I am not sure if this is anything due to PyQL or otherwise.

        So I instead created a DLL of the Quantlib CDS example and then loaded that with the standard library module ctypes. I found the same results– that calling Quantlib, however wrapped (whether cythonized or through ctypes), I cannot get the correct answers. So my feeling is that this has something to do with the C++/Python interaction in general. In all the cases, I have started by setting VS90COMNTOOLS = %VS100COMNTOOLS%, as dpinte suggests above.

        Please let me know if there’s something I may have missed.

      • Didrik says:

        @Sriram: can you run the entire test suite and send me the results? dpinte at The main known issue is with the Settings singletion.

    • Quobarra says:

      stas, can you explain your steps to getting PyQL compile in your setup? I have the exact same setup. I was able to compile boost and quantlib libraries, and after changing the lib and include locations in the, I am still not able to get PyQL to compile and getting linker errors such as this one.

      Any idea why?

      c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\link.exe /DLL /nologo /INCREMENTAL:NO /LIBPATH:C:\sr
      c\cpp\QuantLib-1.2.1\lib /LIBPATH:C:\src\cpp\boost\stage\lib /LIBPATH:C:\Python27\libs /LIBPATH:C:\Python27\PC
      build QuantLib.lib /EXPORT:initcurrency build\temp.win32-2.7\Release\quantlib\currency.obj /OUT:build\lib.win3
      2-2.7\quantlib\currency.pyd /IMPLIB:build\temp.win32-2.7\Release\quantlib\currency.lib /MANIFESTFILE:build\tem
      p.win32-2.7\Release\quantlib\currency.pyd.manifest /subsystem:windows /machine:I386
      msvcprt.lib(MSVCP90.dll) : error LNK2005: “public: __thiscall std::basic_string<char,struct std::char_traits,class std::allocator >::~basic_string<char,struct std::char_traits,class std::allocator
      >(void)” (??1?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@XZ) already defined in QuantLib

      • stas says:

        Hard to tell from the error alone, it it just looks like it can’t resolve references during linking process, but that was obvious …
        I am assuming you are trying to compile a 32-bit version, based on what I see here?

        One detail I left out above – I am using Cython 0.17, without any patches.

  7. [...] PyQL : a new set of Python wrappers for QuantLib « Things and …Mar 23, 2012 … Hi folks,. We are happy to announce the release of PyQL [1], a new set of Python wrappers for QuantLib. The project is available here : … [...]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Get every new post delivered to your Inbox.

%d bloggers like this: