If you have improvements to Neustar-TDI/python-sdk, send us your pull requests! Neustar-TDI/python-sdk is hosted on GitHub at and we welcome contributions of all forms. We use GitHub’s issue tracking and collaboration tools exclusively for managing development.

Getting Started

Working on Neustar-TDI/python-sdk requires additional packages, such as pytest, mock and Sphinx.

$ pip install -r dev_requirements
$ pip install -e .
$ pip install -r docs_requirements

You are now ready to run tests and build documentation.

Running Tests

Unit tests are found in the tests/ directory and are designed to use python’s unittest library. pytest will discover the tests automatically.

$ pytest

Cross-version tests require installing additional Python versions, and setting up the local tox environment:

$ pyenv install 3.6.1
$ pyenv install 3.5.1
$ pyenv install 3.4.0
$ pyenv install 2.7.13
$ pyenv local 3.6.1 3.5.1 3.4.0 2.7.13

Building Documentation

Documentation is stored in the docs/ directory. It is written in reStructedText and rendered using Sphinx.

$ make html

Submitting Bugs


Please report security issues only to This is a private list only open to highly trusted cryptography developers.

  • Check that someone hasn’t already filed the bug by searching GitHub’s issue tracker.
  • Don’t use GitHub’s issue tracker for support questions. Use Stack Overflow and tag Neustar-TDI/python-sdk for that.
  • Provide information so we can replicate the bug on our end. (Python version, SDK version, OS, code samples, et cetera).

Requesting Features

We’re always trying to make Neustar-TDI/python-sdk better, and your feature requests are a key part of that.

  • Check that someone hasn’t already requested the feature by searching GitHub’s issue tracker.
  • Clearly and concisely describe the feature and how you would like to see it implemented. Include example code if possible.
  • Explain why you would like the feature. Sometimes it’s very obvious, other times a use case will help us understand the importance of the requested feature.

Contributing Changes


Always make a new branch for your work, no matter how small!


Don’t submit unrelated changes in the same branch/pull request! We would hate to see an amazing pull request get rejected because it contains a bug in unrelated code.

  • All new functions and classes MUST be documented and accompanied with unit tests.
  • Our coding style follows PEP 8.
  • In docstrings we use reStructedText as described in PEP 287
def foo(bar):
    Makes input string better.

    :param bar: input to make better
    :return: a better input
  • Patches should be small to facilitate easier review.
  • New features should branch off of master and once finished, submit a pull request into develop.
  • develop branch is used to gather all new features for an upcoming release.
  • Bug fixes should be based off the branch named after the oldest supported release the bug affects.
  • If a feature was introduced in 1.1 and the latest release is 1.3, and a bug is found in that feature, make your branch based on 1.1. The maintainer will then forward-port it to 1.3 and master.
  • You MUST have legal permission to distribute any code you contribute to Neustar-TDI/python-sdk.
  • Class names which contains acronyms or initials should always be capitalized. i.e. AESEncrypt not AesEncrypt.