• PyRFA 8.0.0 Dropping Support for RHEL5 and 32-bit Systems

    Recent release of PyRFA 8.0.0 (and forward) has dropped support for 32-bit and RHEL5. It supports only 64-bit systems on both Windows and Linux. The reason to drop the support on 32-bit depends on Thomson Reuters RFA C++ libraries that we use to build PyRFA. And since Thomson Reuters has decided not to include the libraries, PyRFA is affected this way.

    Feature-wise, we will keep maintaining version 7.6.1 as it is the last version with 32-bit and RHEL5 support. All future bug fixes and enhancement made to 8.0.0 will also be ported back to 7.6.1.

    For this case, releases also change the data output format into a pure dictionary just like in 8.0.0.

    Thanks for using PyRFA!

  • PyRFA 8.0.0 Data Output Change

    In PyRFA 8.0.0 onwards, we have changed data output from dispatchEventQueue() to contain only dictionary. This enables Python users to parse and use data more efficiently.

    In previous 7.6.0:

    ('NIP', 'EUR=', {'ASK': '0.999', 'ASK_TIME': '13:41:32:120', 'BID': '0.988', 'BID_NET_CH': '0.0041'})

    Now in 8.0.0:

  • Making Mac Terminal and Windows CMD Support Unicode Charset Display in Python 3

    According to Python 3 unicode character representation, It is possible for the user to confront with Python exception when Terminal is trying to display such unicode data from Pyrfa. Here is the error:

    UnicodeEncodeError: 'ascii' codec can't encode character '\u21e7' in position 1: ordinal not in range(128)

    In this case the '\u21e7' is a unicode for an arrow character. It is a mandatory for the PyRFA users to configure their terminal in order to display these charset according to the Python 3 unicode support. Each of platform can properly display unicode via commands as follows:


    $ export PYTHONIOENCODING=utf-8


    C:\> chcp 65001
  • Expanding Thomson Reuters Elektron Chain RICs with PyRFA

    We got an inquiry today regarding using our PyRFA to expand chain RICs. Here is the methods of expanding chain RICs that we delivered for a bank who used TREP-RT. Chains are comprised of RICs put in a FID LINK_ or LONGLINK divided into pages. Keep looking at NEXT_LR FID for the next chain RIC page and continue extracting actual RIC. Here are some Python code we used:

    def expandChainRIC(self, chainRIC):
            expanded = []
            done = False
            snapshot = self.snapshotRequest([chainRIC])
            while not done:
                if not snapshot:
                for i in ['LINK_1', 'LINK_2', 'LINK_3', 'LINK_4', 'LINK_5', 'LINK_6', 'LINK_7', 'LINK_8', 'LINK_9', 'LINK_10', 'LINK_11', 'LINK_12', 'LINK_13', 'LINK_14', 'LONGLINK1', 'LONGLINK2', 'LONGLINK3', 'LONGLINK4', 'LONGLINK5', 'LONGLINK6', 'LONGLINK7', 'LONGLINK8', 'LONGLINK9', 'LONGLINK10', 'LONGLINK11', 'LONGLINK12', 'LONGLINK13', 'LONGLINK14']:
                    if snapshot[0][2].has_key(i) and snapshot[0][2][i]:
                if snapshot[0][2].has_key('NEXT_LR') and snapshot[0][2]['NEXT_LR']:
                    snapshot = self.snapshotRequest([snapshot[0][2]['NEXT_LR']])
                elif snapshot[0][2].has_key('LONGNEXTLR') and snapshot[0][2]['LONGNEXTLR']:
                    snapshot = self.snapshotRequest([snapshot[0][2]['LONGNEXTLR']])
                    done = True
            # if chainRIC is not a chain, return itself back
            if not expanded:
            if self.debug:
                print "[debug] Expand chain " + chainRIC + " -> " + str(expanded)
            return expanded


    def snapshotRequest(self, ricList):
            snaphots = ()
            self.pyrfa.log("Subscribing items: " + str(ricList) + " (total: " + str(len(ricList)) + " )")
            for ric in ricList:
            global end
            end = False
            t = threading.Timer(10, stop)
            imageReceived = 0
            while not end and imageReceived < len(ricList):
                images = self.pyrfa.dispatchEventQueue()
                if images:
                    for i in images:
                        if type(i[2]) is dict:
                            imageReceived += 1
                            snaphots += (i,)
                            t = threading.Timer(10, stop)
            self.pyrfa.log("Snapshots received: " + str(imageReceived))
            return snaphots
  • PyRFA for RHEL 6.3

    PyRFA is an alternative Python API for accessing Thomson Reuters real-time data feeds such as IDN, TS1 (time-series service), TREP-RT, RMDS or RDF-D from Thomson Reuters leveraging on OMM data model available in streaming or snapshot mode. Due to recent request from many buy-side/sell-side, brokers and banks around the world today DevCartel is pleased to announce the release of PyRFA v7.5.1.2 with support for Red Hat Enterprise Linux 6.3. PyRFA has extended its support to Red Hat 6.3 that comes with Python 2.6 as we see the needs from users to run financial Python applications on RHEL. So enjoy!

    See more at http://devcartel.com/pyrfa

  • PyRFA Now with TS1 Timeseries

    One of new features in PyRFA is ability to retrieve a full set of timeseries from Thomson Reuters TS1 service. PyRFA makes it unapologetically easy to request and decode TS1 in a few simple steps.

    Timeseries example script:

    import pyrfa
    p = pyrfa.Pyrfa()
    timeseries = p.getTimeSeries("CHK.N")
    print "\n########### CHK.N daily ###########"
    for record in timeseries:
    print record


    ########### CHK.N daily  ###########
  • How to Save PyRFA Log

    Every time you run a PyRFA script, it will write a log file to a location specified by:

    \Logger\AppLogger\fileLoggerFilename = "./pyrfa.log"

    In the configuration. However, special options are allowed to append various unique prefix/suffix in the filename to avoid log file overwritten. Those options are:

    • {A} for process name
    • {P} for process ID
    • {T} for local 10-digit timestamp in UTC
    • {H} for hostname
    For example,
    \Logger\AppLogger\fileLoggerFilename = "./pyrfa.log.{T}"

    Will put a timestamp as a log file suffix and we will have a unique log file for every run.