Package Health Score

58 / 100

security
No known security issues
popularity
Popular
maintenance
Inactive
community
Sustainable

Popularity

Popular

GitHub Stars: 531
Forks: 87
Contributors: 20

Direct Usage Popularity

Based on project statistics from the GitHub repository for the PyPI package datrie, we found that it has been starred 531 times.

Security

No known security issues

Security and license risk for latest version

Release Date: Mar 26, 2020
Direct Vulnerabilities: 0
C
0
H
0
M
0
L
Indirect Vulnerabilities: 0
C
0
H
0
M
0
L
License Risk: 0
H
1
M
0
L

All security vulnerabilities belong to production dependencies of direct and indirect packages.

License

LGPL-2.1

Non-Permissive License

We noticed that this project uses a license which requires less permissive conditions such as disclosing the source code, stating changes or redistributing the source under the same license. It is advised to further consult the license terms before use.

Security Policy

We found a way for you to contribute to the project! Looks like datrie is missing a security policy.

You can connect your project's repository to Snyk to stay up to date on security alerts and receive automatic fix pull requests.

Keep your project free of vulnerabilities with Snyk

Maintenance

Inactive

Commit Frequency

No Recent Commits

Open Issues: 29
Open PR: 10
Last Release: 5 years ago
Last Commit: 5 years ago

Further analysis of the maintenance status of datrie based on released PyPI versions cadence, the repository activity, and other data points determined that its maintenance is Inactive.

An important project maintenance signal to consider for datrie is that it hasn't seen any new versions released to PyPI in the past 12 months, and could be considered as a discontinued project, or that which receives low attention from its maintainers.

In the past month we didn't find any pull request activity or change in issues status has been detected for the GitHub repository.

Community

Sustainable

Readme: Yes
Contributing.md: No
Code of Conduct: No
Contributors: 20
Funding: No

With more than 10 contributors for the datrie repository, this is possibly a sign for a growing and inviting community.

We found a way for you to contribute to the project! Looks like datrie is missing a Code of Conduct.

Embed Package Health Score Badge

Keep your project healthy

Check your requirements.txt

Ensure all the packages you're using are healthy and well-maintained

Snyk Vulnerability Scanner

Get health score & security insights directly in your IDE

Package

Python Versions Compatibility: >=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*

Age: 12 years
Latest Release: 5 years ago
Dependencies: N/A
Versions: 15
Maintainers: 0
Wheels: Linux, macOS, Windows

Readme

datrie

Super-fast, efficiently stored Trie for Python (2.x and 3.x). Uses libdatrie.

Installation

pip install datrie

Usage

Create a new trie capable of storing items with lower-case ascii keys:

&gt;&gt;&gt; import string
&gt;&gt;&gt; import datrie
&gt;&gt;&gt; trie = datrie.Trie(string.ascii_lowercase)

trie variable is a dict-like object that can have unicode keys of certain ranges and Python objects as values.

In addition to implementing the mapping interface, tries facilitate finding the items for a given prefix, and vice versa, finding the items whose keys are prefixes of a given string. As a common special case, finding the longest-prefix item is also supported.

Warning

For efficiency you must define allowed character range(s) while creating trie. datrie doesn't check if keys are in allowed ranges at runtime, so be careful! Invalid keys are OK at lookup time but values won't be stored correctly for such keys.

Add some values to it (datrie keys must be unicode; the examples are for Python 2.x):

&gt;&gt;&gt; trie[u'foo'] = 5
&gt;&gt;&gt; trie[u'foobar'] = 10
&gt;&gt;&gt; trie[u'bar'] = 'bar value'
&gt;&gt;&gt; trie.setdefault(u'foobar', 15)
10

Check if u'foo' is in trie:

&gt;&gt;&gt; u'foo' in trie
True

Get a value:

&gt;&gt;&gt; trie[u'foo']
5

Find all prefixes of a word:

&gt;&gt;&gt; trie.prefixes(u'foobarbaz')
[u'foo', u'foobar']

&gt;&gt;&gt; trie.prefix_items(u'foobarbaz')
[(u'foo', 5), (u'foobar', 10)]

&gt;&gt;&gt; trie.iter_prefixes(u'foobarbaz')


&gt;&gt;&gt; trie.iter_prefix_items(u'foobarbaz')

Find the longest prefix of a word:

&gt;&gt;&gt; trie.longest_prefix(u'foo')
u'foo'

&gt;&gt;&gt; trie.longest_prefix(u'foobarbaz')
u'foobar'

&gt;&gt;&gt; trie.longest_prefix(u'gaz')
KeyError: u'gaz'

&gt;&gt;&gt; trie.longest_prefix(u'gaz', default=u'vasia')
u'vasia'

&gt;&gt;&gt; trie.longest_prefix_item(u'foobarbaz')
(u'foobar', 10)

Check if the trie has keys with a given prefix:

&gt;&gt;&gt; trie.has_keys_with_prefix(u'fo')
True

&gt;&gt;&gt; trie.has_keys_with_prefix(u'FO')
False

Get all items with a given prefix from a trie:

&gt;&gt;&gt; trie.keys(u'fo')
[u'foo', u'foobar']

&gt;&gt;&gt; trie.items(u'ba')
[(u'bar', 'bar value')]

&gt;&gt;&gt; trie.values(u'foob')
[10]

Get all suffixes of certain word starting with a given prefix from a trie:

&gt;&gt;&gt; trie.suffixes()
[u'pro', u'producer', u'producers', u'product', u'production', u'productivity', u'prof']
&gt;&gt;&gt; trie.suffixes(u'prod')
[u'ucer', u'ucers', u'uct', u'uction', u'uctivity']

Save & load a trie (values must be picklable):

&gt;&gt;&gt; trie.save('my.trie')
&gt;&gt;&gt; trie2 = datrie.Trie.load('my.trie')

Trie and BaseTrie

There are two Trie classes in datrie package: datrie.Trie and datrie.BaseTrie. datrie.BaseTrie is slightly faster and uses less memory but it can store only integer numbers -2147483648 <= x <= 2147483647. datrie.Trie is a bit slower but can store any Python object as a value.

If you don't need values or integer values are OK then use datrie.BaseTrie:

import datrie
import string
trie = datrie.BaseTrie(string.ascii_lowercase)

Custom iteration

If the built-in trie methods don't fit you can use datrie.State and datrie.Iterator to implement custom traversal.

Note

If you use datrie.BaseTrie you need datrie.BaseState and datrie.BaseIterator for custom traversal.

For example, let's find all suffixes of 'fo' for our trie and get the values:

&gt;&gt;&gt; state = datrie.State(trie)
&gt;&gt;&gt; state.walk(u'foo')
&gt;&gt;&gt; it = datrie.Iterator(state)
&gt;&gt;&gt; while it.next():
...     print(it.key())
...     print(it.data))
o
5
obar
10

Performance

Performance is measured for datrie.Trie against Python's dict with 100k unique unicode words (English and Russian) as keys and '1' numbers as values.

datrie.Trie uses about 5M memory for 100k words; Python's dict uses about 22M for this according to my unscientific tests.

This trie implementation is 2-6 times slower than python's dict on __getitem__. Benchmark results (macbook air i5 1.8GHz, "1.000M ops/sec" == "1 000 000 operations per second"):

Python 2.6:
dict __getitem__: 7.107M ops/sec
trie __getitem__: 2.478M ops/sec

Python 2.7:
dict __getitem__: 6.550M ops/sec
trie __getitem__: 2.474M ops/sec

Python 3.2:
dict __getitem__: 8.185M ops/sec
trie __getitem__: 2.684M ops/sec

Python 3.3:
dict __getitem__: 7.050M ops/sec
trie __getitem__: 2.755M ops/sec

Looking for prefixes of a given word is almost as fast as __getitem__ (results are for Python 3.3):

trie.iter_prefix_items (hits):      0.461M ops/sec
trie.prefix_items (hits):           0.743M ops/sec
trie.prefix_items loop (hits):      0.629M ops/sec
trie.iter_prefixes (hits):          0.759M ops/sec
trie.iter_prefixes (misses):        1.538M ops/sec
trie.iter_prefixes (mixed):         1.359M ops/sec
trie.has_keys_with_prefix (hits):   1.896M ops/sec
trie.has_keys_with_prefix (misses): 2.590M ops/sec
trie.longest_prefix (hits):         1.710M ops/sec
trie.longest_prefix (misses):       1.506M ops/sec
trie.longest_prefix (mixed):        1.520M ops/sec
trie.longest_prefix_item (hits):    1.276M ops/sec
trie.longest_prefix_item (misses):  1.292M ops/sec
trie.longest_prefix_item (mixed):   1.379M ops/sec

Looking for all words starting with a given prefix is mostly limited by overall result count (this can be improved in future because a lot of time is spent decoding strings from utf_32_le to Python's unicode):

trie.items(prefix="xxx"), avg_len(res)==415:        0.609K ops/sec
trie.keys(prefix="xxx"), avg_len(res)==415:         0.642K ops/sec
trie.values(prefix="xxx"), avg_len(res)==415:       4.974K ops/sec
trie.items(prefix="xxxxx"), avg_len(res)==17:       14.781K ops/sec
trie.keys(prefix="xxxxx"), avg_len(res)==17:        15.766K ops/sec
trie.values(prefix="xxxxx"), avg_len(res)==17:      96.456K ops/sec
trie.items(prefix="xxxxxxxx"), avg_len(res)==3:     75.165K ops/sec
trie.keys(prefix="xxxxxxxx"), avg_len(res)==3:      77.225K ops/sec
trie.values(prefix="xxxxxxxx"), avg_len(res)==3:    320.755K ops/sec
trie.items(prefix="xxxxx..xx"), avg_len(res)==1.4:  173.591K ops/sec
trie.keys(prefix="xxxxx..xx"), avg_len(res)==1.4:   180.678K ops/sec
trie.values(prefix="xxxxx..xx"), avg_len(res)==1.4: 503.392K ops/sec
trie.items(prefix="xxx"), NON_EXISTING:             2023.647K ops/sec
trie.keys(prefix="xxx"), NON_EXISTING:              1976.928K ops/sec
trie.values(prefix="xxx"), NON_EXISTING:            2060.372K ops/sec

Random insert time is very slow compared to dict, this is the limitation of double-array tries; updates are quite fast. If you want to build a trie, consider sorting keys before the insertion:

dict __setitem__ (updates):            6.497M ops/sec
trie __setitem__ (updates):            2.633M ops/sec
dict __setitem__ (inserts, random):    5.808M ops/sec
trie __setitem__ (inserts, random):    0.053M ops/sec
dict __setitem__ (inserts, sorted):    5.749M ops/sec
trie __setitem__ (inserts, sorted):    0.624M ops/sec
dict setdefault (updates):             3.455M ops/sec
trie setdefault (updates):             1.910M ops/sec
dict setdefault (inserts):             3.466M ops/sec
trie setdefault (inserts):             0.053M ops/sec

Other results (note that len(trie) is currently implemented using trie traversal):

dict __contains__ (hits):    6.801M ops/sec
trie __contains__ (hits):    2.816M ops/sec
dict __contains__ (misses):  5.470M ops/sec
trie __contains__ (misses):  4.224M ops/sec
dict __len__:                334336.269 ops/sec
trie __len__:                22.900 ops/sec
dict values():               406.507 ops/sec
trie values():               20.864 ops/sec
dict keys():                 189.298 ops/sec
trie keys():                 2.773 ops/sec
dict items():                48.734 ops/sec
trie items():                2.611 ops/sec

Please take this benchmark results with a grain of salt; this is a very simple benchmark and may not cover your use case.

Current Limitations

keys must be unicode (no implicit conversion for byte strings under Python 2.x, sorry);
there are no iterator versions of keys/values/items (this is not implemented yet);
it is painfully slow and maybe buggy under pypy;
library is not tested with narrow Python builds.

Contributing

Development happens at github: .

Feel free to submit ideas, bugs, pull requests.

Running tests and benchmarks

Make sure tox is installed and run

$ tox

from the source checkout. Tests should pass under Python 2.7 and 3.4+.

$ tox -c tox-bench.ini

runs benchmarks.

If you've changed anything in the source code then make sure cython is installed and run

$ update_c.sh

before each tox command.

Please note that benchmarks are not included in the release tar.gz's because benchmark data is large and this saves a lot of bandwidth; use source checkouts from github or bitbucket for the benchmarks.

Authors & Contributors

See .

This module is based on libdatrie C library by Theppitak Karoonboonyanan and is inspired by fast_trie Ruby bindings, PyTrie pure Python implementation and Tree::Trie Perl implementation; some docs and API ideas are borrowed from these projects.

License

Licensed under LGPL v2.1. CHANGES =======

0.8.2 (2020-03-25)

Future-proof Python support by making cython a build time dependency and removing cython generated c files from the repo (and sdist).
Fix collections.abc.MutableMapping import
CI and test updates
Adjust library name to unbreak some linkers

0.8.1 (skipped)

This version intentionally skipped

0.8 (2019-07-03)

Python 3.7 compatibility; extension is rebuilt with Cython 0.29.11.
Trie.get function;
Python 2.6 and 3.3 support is dropped;
removed patch to libdatrie which is no longer required;
testing and CI fixes.

0.7.1 (2016-03-12)

updated the bundled C library to version 0.2.9;
implemented Trie.__len__ in terms of trie_enumerate;
rebuilt Cython wrapper with Cython 0.23.4;
changed Trie to implement collections.abc.MutableMapping;
fixed Trie pickling, which segfaulted on Python2.X.

0.7 (2014-02-18)

bundled libdatrie C library is updated to version 0.2.8;
new .suffixes() method (thanks Ahmed T. Youssef);
wrapper is rebuilt with Cython 0.20.1.

0.6.1 (2013-09-21)

fixed build for Visual Studio (thanks Gabi Davar).

0.6 (2013-07-09)

datrie is rebuilt with Cython 0.19.1;
iter_prefix_values, prefix_values and longest_prefix_value methods for datrie.BaseTrie and datrie.Trie (thanks Jared Suttles).

0.5.1 (2013-01-30)

Recently introduced memory leak in longest_prefix and longest_prefix_item is fixed.

0.5 (2013-01-29)

longest_prefix and longest_prefix_item methods are fixed;
datrie is rebuilt with Cython 0.18;
misleading benchmark results in README are fixed;
State._walk is renamed to State.walk_char.

0.4.2 (2012-09-02)

Update to latest libdatrie; this makes .keys() method a bit slower but removes a keys length limitation.

0.4.1 (2012-07-29)

cPickle is used for saving/loading datrie.Trie if it is available.

0.4 (2012-07-27)

libdatrie improvements and bugfixes, including C iterator API support;
custom iteration support using datrie.State and datrie.Iterator.
speed improvements: __length__, keys, values and items methods should be up to 2x faster.
keys longer than 32768 are not supported in this release.

0.3 (2012-07-21)

There are no new features or speed improvements in this release.

datrie.new is deprecated; use datrie.Trie with the same arguments;
small test & benchmark improvements.

0.2 (2012-07-16)

datrie.Trie items can have any Python object as a value (Trie from 0.1.x becomes datrie.BaseTrie);
longest_prefix and longest_prefix_items are fixed;
save & load are rewritten;
setdefault method.

0.1.1 (2012-07-13)

Windows support (upstream libdatrie changes are merged);
license is changed from LGPL v3 to LGPL v2.1 to match the libdatrie license.

0.1 (2012-07-12)

Initial release.

FAQs

What is datrie?

Super-fast, efficiently stored Trie for Python. Visit Snyk Advisor to see a full health score report for datrie, including popularity, security, maintenance & community analysis.

Is datrie popular?

The python package datrie receives a total of 14,804 weekly downloads. As such, datrie popularity was classified as a popular. Visit the popularity section on Snyk Advisor to see the full health analysis.

Is datrie well maintained?

We found indications that datrie is an Inactive project. See the full package health analysis to learn more about the package maintenance status.

Is datrie safe to use?

The python package datrie was scanned for known vulnerabilities and missing license, and no issues were found. Thus the package was deemed as safe to use. See the full health analysis review.

Last updated on 20 December-2024, at 23:04 (UTC).

Build a secure application checklist

Select a recommended open source package

Minimize your risk by selecting secure & well maintained open source packages

DONE

Scan your app for vulnerabilities

Scan your application to find vulnerabilities in your: source code, open source dependencies, containers and configuration files

SCAN NOW

Fix identified vulnerabilities

Easily fix your code by leveraging automatically generated PRs

AUTO FIX

Monitor for new issues

New vulnerabilities are discovered every day. Get notified if your application is affected

MONITOR APP

Package Health Score

Direct Usage Popularity

Security and license risk for latest version

Commit Frequency

Embed Package Health Score Badge

Keep your project healthy

Check your requirements.txt

Snyk Vulnerability Scanner

Readme

datrie

Installation

Usage

Trie and BaseTrie

Custom iteration

Performance

Current Limitations

Contributing

Running tests and benchmarks

Authors & Contributors

License

0.8.2 (2020-03-25)

0.8.1 (skipped)

0.8 (2019-07-03)

0.7.1 (2016-03-12)

0.7 (2014-02-18)

0.6.1 (2013-09-21)

0.6 (2013-07-09)

0.5.1 (2013-01-30)

0.5 (2013-01-29)

0.4.2 (2012-09-02)

0.4.1 (2012-07-29)

0.4 (2012-07-27)

0.3 (2012-07-21)

0.2 (2012-07-16)

0.1.1 (2012-07-13)

0.1 (2012-07-12)

FAQs

What is datrie?

Is datrie popular?

Is datrie well maintained?

Is datrie safe to use?

Build a secure application checklist

Select a recommended open source package

Scan your app for vulnerabilities

Source Code

Open Source

Container

Config

Fix identified vulnerabilities

Monitor for new issues