Contributing guidelines — TextBlob 0.19.0 documentation (original) (raw)

In General¶

• PEP 8, when sensible.
• Conventions and configuration.
• TextBlob wraps functionality in NLTK and pattern.en. Anything outside of that should be written as an extension.
• Test ruthlessly. Write docs for new features.
• Even more important than Test-Driven Development–Human-Driven Development.
• These guidelines may–and probably will–change.

In Particular¶

Questions, Feature Requests, Bug Reports, and Feedback…¶

…should all be reported on the Github Issue Tracker .

Setting Up for Local Development¶

1. Fork TextBlob on Github.
   $ git clone https://github.com/sloria/TextBlob.git
   $ cd TextBlob
2. Install development requirements. It is highly recommended that you use a virtualenv.

After activating your virtualenv

$ pip install -e '.[tests]'

Developing Extensions¶

Extensions are packages with the name textblob-something, where “something” is the name of your extension. Extensions should be imported with import textblob_something.

Model Extensions¶

To create a new extension for a part-of-speech tagger, sentiment analyzer, noun phrase extractor, classifier, tokenizer, or parser, simply create a module that has a class that implements the correct interface from textblob.base. For example, a tagger might look like this:

from textblob.base import BaseTagger

class MyTagger(BaseTagger): def tag(self, text): pass # Your implementation goes here

Language Extensions¶

The process for developing language extensions is the same as developing model extensions. Create your part-of-speech taggers, tokenizers, parsers, etc. in the language of your choice. Packages should be named textblob-xx where “xx” is the two- or three-letter language code (Language code reference).

To see examples of existing extensions, visit the Extensions page.

Check out the API reference for more info on the model interfaces.

Git Branch Structure¶

TextBlob loosely follows Vincent Driessen’s Successful Git Branching Model . In practice, the following branch conventions are used:

dev

The next release branch.

master

Current production release on PyPI.

Pull Requests¶

1. Create a new local branch.

$ git checkout -b name-of-feature

2. Commit your changes. Write good commit messages.

$ git commit -m "Detailed commit message" $ git push origin name-of-feature

1. Before submitting a pull request, check the following:

• If the pull request adds functionality, it is tested and the docs are updated.
• If you’ve developed an extension, it is on the Extensions List.
• You’ve added yourself to AUTHORS.rst.

1. Submit a pull request to the sloria:dev branch.

Running tests¶

To run all the tests:

To skip slow tests:

Documentation¶

Contributions to the documentation are welcome. Documentation is written in reStructuredText (rST). A quick rST reference can be found here. Builds are powered by Sphinx.

To build docs and run in watch mode: