mlenzen/collections-extended

Extra Python Collections - bags (multisets), setlists (unique list / indexed set), RangeMap and IndexedDict

collections-extended's Issues

hash(frozenbag()) == hash(frozenbag(tuple()))

Solution - xor all elements

Test Python 3.5

bag.unique_items returns a list

This breaks or

Add simple examples to README

Does Set._hash work on bags?

setlist.add should not raise ValueError if the value is already present

This will match Set.add API and will also provide an alternative to setlist.append which does raise a ValueError if the value is present.

Documentation page for bijections

Import everything from Google Code

Fix doctests for bags that rely on the order of the output

bags comparisons should return NotImplemented

setlist - Rename remove_all to discard_all?

remove_all matches the behavior of discard not remove in that it doesn't raise ValueErrors and just ignores elements to be removed that aren't present.

setlists don't support slicing

setlist.getitem should return a setlist
setlist.setitem and delitem don't work

requirements.txt cleanup

general requirements.txt unnecessary - setup.py handles it

consolidate requirements-dev.txt and requirements-doc.txt?

setlist comparisons do not look like they work

Move source into a package dir

setlist.sub_index returns nothing in some cases

If the first element of the subsequence isn't in the setlist, nothing is returned.
If a TypeError is raised (when does this happen?) nothing is returned.

Compare bags and setlists to common implementations

eg. bags to collections.Counter

RangeMap del should raise a KeyError if the range isn't mapped

rm = RangeMap({1: 'a', 2: 'b', 3: 'c', 4: 'd', 5: 'e'})
del rm[2:3]
del rm[2:3]

Second should raise an error

rm = RangeMap({1: 'a', 2: 'b', 3: 'c', 4: 'd', 5: 'e'})
del rm[0:2]

Should raise an error.

bags comparisons __gt__ shouldn't rely on __lt__ being implemented on other

Should return NotImplemented instead of raising an error.
__gt__ shouldn't rely on __lt__ being implemented on other.

RangeMap.__repr__ can use implicit repr for value when formatting string

Back range_map._ordered_keys with a binary tree instead of list?

Badges?

Use badges from http://shields.io/ for consistent look?
Any more badges to add?

random.shuffle(setlist) doesn't work

Is there a problem assigning values?

Add setlist.copy()

RangeMap.__repr__ is formatted badly

It doesn't yield an string that can be used to recreate it or is even valid Python.

eg:
RangeMap((None, None): 'a')

doc tests fail for 2.6 because there was no collections.Counter

remove docs from automated testing?

Set hash function doesn't work on bags in 2.7

Coverage causes tests to fail for Python 3.2

https://travis-ci.org/mlenzen/collections-extended/jobs/85969424

New RangeMap implementation doesn't work with older versions of Python.

Remove Last() and First(). Get rid of hypothesis for testing.

Python 2.7 compatibility

setlist.__setitem__ should raise a ValueError when inserting an existing value

Back RangeMap with more efficient datastructure

A binary tree or sorteddict (from blist) would probably be more efficient.

Bags to accept non-hashable elements

Bags should accept non-hashable elements. Currently a bag is backed by a
dict, so you can't add a bag to another bag.

setlist.count doesn't count the last item

bidict

Hi @mlenzen, I am the author of bidict, a Python library that focuses on bidirectional maps. I just came across your library's bijection, and was wondering if you already knew about bidict when you wrote bijection, and either way, what you think of it. (Also, fun to see how similarly the .inverse property is implemented under the hood.) Just wanted to invite you to join forces if you're interested, as we're covering some overlapping ground. Best wishes!

make bag._from_mapping public

Testing migration

Move away from doctests.
Travis CI integration

RangeMap to implement Sized, Iterable and Mapping

Iterate and count keys (ranges) like other mappings.

setlist.extend should be atomic

Extending a setlist should either add all of the items or none, right now it appends elements until it hits one that already exists.

set operations fail for bag.unique_elements

Should setlists quietly reject duplicate values or raise a ValueError?

__init__ silently ignores them
other methods raise ValueErrors

RangeMap comparison

rm = RangeMap({1: 'a', 2: 'b', 3: 'c', 4: 'd', 5: 'e'})
del rm[1:2]
assert rm == RangeMap({2: 'b', 3: 'c', 4: 'd', 5: 'e'})

Comparing the _key_mapping dicts doesn't work because 1 is mapped to _empty

Add examples to setlist doc page

bag.__isub__ will raise a ValueError and remove some elements if one isn't present

Should we first check that we can remove all of the elements first, raise a ValueError if we can't, and if we can then remove all of the elements. Then we won't be left in a state where only some elements get removed.

Add annotations

_basesetlist.sub_index should accept any iterable

Right now it uses indices to access elements, we can just iterate over them and accept any iterable

Collection comparison

What types of Collections should be comparable to each other?
If a set and a bag contain the same elements with the same multiplicity
should they be equal? For a list and a setlist?

I think sets and bags should be comparable, a bag can be a subset of a set
and vice versa. The relationship is well defined and already in Python for
set comparisons.

Explicitly inherit methods so docs can be provided

Good docstrings (for Sphinx)

Consistent naming - either data structures or collections extended