API: add "level=" argument to MultiIndex.unique() #17897

toobaz · 2017-10-16T18:00:18Z

closes API: support "unique=True" in MultiIndex.get_level_values() #17896
tests added / passed
passes git diff master -u -- "*.py" | flake8 --diff
whatsnew entry

jreback · 2017-10-16T18:06:23Z

pandas/core/indexes/multi.py

@@ -896,20 +896,24 @@ def _get_level_values(self, level):
        Parameters
        ----------
        level : int level
+        unique : bool


you need to add a version added tag

need a versionadded tag

I added it, and then removed it on @jorisvandenbossche 's suggestion because this is an internal method.

add the default value in the doc string

u can remove the versionadded tag here

toobaz · 2017-10-16T18:06:36Z

From #17881 , @jreback 's comments:

I am not sure unique is the right word here.

I'm not a fan either...

.get_level_values(level, used=False), though I am not sure I like this either.

... but I think this would be pretty confusing ("used" as in "this label appears in the index" vs. "used" as "this label is used multiple times")

toobaz · 2017-10-16T18:08:14Z

Alternatives:

MultiIndex.get_level_values(idx, drop_duplicates=False)
MultiIndex.get_level_values(idx, duplicated=True)

jreback · 2017-10-16T18:11:15Z

how about remove_unused_levels=False, so then remove_unused_levels is obvious

toobaz · 2017-10-16T18:47:36Z

how about remove_unused_levels=False, so then remove_unused_levels is obvious

you mean "levels" or "labels"? Anyway, not following you: get_level_values() always removes unused labels... the particularity of this is that (used) labels only appear once.

codecov · 2017-10-16T18:55:45Z

Codecov Report

Merging #17897 into master will decrease coverage by 0.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master   #17897      +/-   ##
==========================================
- Coverage   91.23%   91.22%   -0.02%     
==========================================
  Files         163      163              
  Lines       50105    50107       +2     
==========================================
- Hits        45715    45708       -7     
- Misses       4390     4399       +9

Flag	Coverage Δ
#multiple	`89.03% <100%> (ø)`	⬆️
#single	`40.31% <75%> (-0.06%)`	⬇️

Impacted Files	Coverage Δ
pandas/core/indexes/multi.py	`96.4% <100%> (ø)`	⬆️
pandas/io/gbq.py	`25% <0%> (-58.34%)`	⬇️
pandas/core/frame.py	`97.75% <0%> (-0.1%)`	⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5bf7f9a...8a69543. Read the comment docs.

codecov · 2017-10-16T18:55:48Z

Codecov Report

Merging #17897 into master will decrease coverage by 0.04%.
The diff coverage is 95.23%.

@@            Coverage Diff             @@
##           master   #17897      +/-   ##
==========================================
- Coverage   91.38%   91.34%   -0.05%     
==========================================
  Files         164      164              
  Lines       49797    49812      +15     
==========================================
- Hits        45508    45501       -7     
- Misses       4289     4311      +22

Flag	Coverage Δ
#multiple	`89.14% <95.23%> (-0.03%)`	⬇️
#single	`39.55% <61.9%> (-0.06%)`	⬇️

Impacted Files	Coverage Δ
pandas/core/indexes/base.py	`96.42% <100%> (ø)`	⬆️
pandas/core/indexes/multi.py	`96.4% <100%> (+0.02%)`	⬆️
pandas/core/indexes/category.py	`97.2% <75%> (-0.26%)`	⬇️
pandas/io/gbq.py	`25% <0%> (-58.34%)`	⬇️
pandas/plotting/_converter.py	`63.44% <0%> (-1.82%)`	⬇️
pandas/core/frame.py	`97.8% <0%> (-0.1%)`	⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a172ff9...feb65ed. Read the comment docs.

jschendel · 2017-10-16T20:14:59Z

doc/source/whatsnew/v0.21.0.txt

@@ -792,6 +792,7 @@ Other API Changes
 - Pandas no longer registers matplotlib converters on import. The converters
  will be registered and used when the first plot is draw (:issue:`17710`)
 - Setting on a column with a scalar value and 0-len index now raises a ``ValueError`` (:issue:`16823`)
+- :func:`MultiIndex.get_level_values` now supports the `unique` argument (:issue:`17896`)


Should unique have double ticks here, ``unique``?

toobaz · 2017-10-16T22:39:13Z

Answering @jorisvandenbossche from here:

I agree it would be nice to have a clean way to get those unique values, but IMO it does not belong in get_level_values. That method returns the actual values of the Index level, with a length equal to the length of the Index, and IMO we should stick to that contract. Having such a keyword would completely alter the return type of this method.

(not directly a good idea for alternative though)

I'm open to alternatives, but let me summarize my rationale for working on get_level_values():

the difference between mi.levels ("implementation detail") and mi.get_level_values() (the "effective" content of the index level) has always confused users, but at least it finally reduces to remembering the difference between the two. In this sense, the set of "effective" unique values appearing in the level clearly pertains to the second.
I've always considered the get_level_values() name itself misleading - it reminds me of something like value_counts(), not of something like mi.levels[idx] or df[col], which get entire levels/columns. If I had to redesign the API from scratch, I would probably call get_level_values() precisely the version with unique=True (and get_level() the version with unique=False)
in general, I would like to avoid adding new methods to an API which already has too many
(whatever choice we make for the API, the work will be done by the internal _get_level_values, but this is an implementation detail)

All this said, an alternative which I would find elegant enough would be to add an argument level to MultiIndex.unique(). It could even accept a list, which could be useful. The only disadvantage I see would be that it would deviate from the signature of Index.unique(), but after all this already happens for MultiIndex.drop(level=).

toobaz · 2017-10-17T07:31:39Z

Two additional elements in favor of get_level_values():

we might want to add an argument sort= which switches between the order the elements appear in mi.levels[level] and the order the elements appear in mi (the implementation is trivial). This would be specific to MultiIndexes (sorting might be undefined for a generic Index) and hence a bit out of place in MultiIndex.unique(). Vice-versa, it would be trivial (albeit of limited utility) to support it also in conjunction with unique=False.
the standard way as of now to (inefficiently) obtain the same result is precisely mi.get_level_values(level).unique()

jorisvandenbossche · 2017-10-17T09:24:57Z

OK, trying to clarify my rationale for objecting adding it to get_level_values.

So indeed we have to distinguish the levels (the "unique labels" for each level) and the get_level_values (the "effective values" inside one level, as a full Index). And I agree that the naming is not ideal (additionally with labels not being the labels but the integer codes ..).

In this sense, the set of "effective" unique values appearing in the level clearly pertains to the second.

You could indeed see it that way (unique "effective values"), but I would rather see it as the used "unique labels". If you look at it like that, it clearly pertains to the first ..

In that sense, suppose we had a method like .get_level(i) (which would be equivalent to .levels[i]), I think it would have belonged in that method: something like .get_level(i, remove_unused=True).
But of course, we don't have that method, and I agree we should avoid adding new methods ..

All this said, an alternative which I would find elegant enough would be to add an argument level to MultiIndex.unique()

This actually sounds like a nice alternative.

jorisvandenbossche · 2017-10-17T09:26:19Z

the standard way as of now to (inefficiently) obtain the same result is precisely mi.get_level_values(level).unique()

or mi.remove_unused_levels().levels[i] (which will also be more efficient)

toobaz · 2017-10-17T10:17:01Z

or mi.remove_unused_levels().levels[i] (which will also be more efficient)

Good point. Still, it's recent and hence probably not very well known. And in principle less efficient for short indexes with multiple long levels.

Anyway, I'm OK with changing this PR to MultiIndex.unique(level=): @jreback what do you think?

jreback · 2017-10-17T10:35:04Z

Anyway, I'm OK with changing this PR to MultiIndex.unique(level=): @jreback what do you think?

seems reasonable.

alternatively, .get_levels() is available, sure I don't like expanding the API but it is explicit.

toobaz · 2017-10-17T12:50:42Z

alternatively, .get_levels() is available, sure I don't like expanding the API but it is explicit.

I'm afraid it would be confusing (I would love to swap its name with get_level_values(), but it's too late), so I went for unique(level=).

jreback · 2017-10-17T13:51:39Z

pandas/core/indexes/multi.py

@@ -945,6 +951,34 @@ def get_level_values(self, level):
        values = self._get_level_values(level)
        return values

+    def unique(self, level=None):


I would add the level=None kw to Index.unique as well (for compat. It should raise if its not None).

OK, would you mention it in the (Index) docs?

jorisvandenbossche · 2017-10-18T14:12:45Z

pandas/tests/indexes/test_multi.py

+        expected = Index(['foo', 'bar', 'baz', 'qux'],
+                         name='first')
+        tm.assert_index_equal(result, expected)
+        assert result.name == 'first'


this is already done by assert_index_equal

jorisvandenbossche · 2017-10-18T14:14:37Z

pandas/tests/indexes/test_multi.py

+        arrays = [['a', 'b', 'b'], [2, np.nan, 2]]
+        index = pd.MultiIndex.from_arrays(arrays)
+        values = index.unique(level=1)
+        expected = np.array([2], dtype=np.int64)


For a normal index, the NaN is included in the uniques.

jorisvandenbossche · 2017-10-18T14:15:19Z

pandas/tests/indexes/test_multi.py

+        index = pd.MultiIndex.from_arrays(arrays)
+        values = index.unique(level=1)
+        expected = np.array([2], dtype=np.int64)
+        tm.assert_numpy_array_equal(values.values, expected)


Why are you testing here the .values and not comparing with an Index object ?

jorisvandenbossche · 2017-10-18T14:16:20Z

pandas/core/indexes/multi.py

+        unique : bool
+            if True, drop duplicated values
+
+            .. versionadded:: 0.21.0


this is not needed for an internal method IMO

ah, I see that actually @jreback asked to add it above. But still, I don't think this should be added for internal private functions, as internal code should never have to care about the pandas version

jorisvandenbossche · 2017-10-18T14:18:09Z

pandas/core/indexes/multi.py

+
+        Parameters
+        ----------
+        level : int, optional, defaults None


Should you be able to both specify int or level name ?

toobaz · 2017-10-30T09:05:14Z

The first xfail is unrelated to my patch to the code, and just reflects the fact that I replaced tm.assert_numpy_array_equal with tm.assert_index_equal, as suggested by @jorisvandenbossche

jreback · 2017-10-31T01:30:42Z

can you rebase and will take a look.

jreback · 2017-10-31T01:30:57Z

pandas/core/indexes/base.py

-    def unique(self):
+    def unique(self, level=None):
+        if level not in {0, self.name, None}:
+            raise ValueError("Level {} not found".format(level))


test for this?

They are here

is the doc string for unique updated?

No, because you never replied to my question

not sure what the question is

jreback · 2017-10-31T01:31:05Z

pandas/core/indexes/multi.py

@@ -896,20 +896,24 @@ def _get_level_values(self, level):
        Parameters
        ----------
        level : int level
+        unique : bool


need a versionadded tag

jreback · 2017-10-31T01:31:43Z

pandas/tests/indexes/test_base.py

@@ -1484,6 +1484,24 @@ def test_get_level_values(self):
        result = index_with_name.get_level_values('a')
        tm.assert_index_equal(result, index_with_name)

+    def test_unique(self):
+        idx = pd.Index([2, 3, 2, 1], name='my_index')


can you add the issue number

jreback · 2017-10-31T01:33:27Z

pandas/tests/indexes/test_base.py

+    def test_unique(self):
+        idx = pd.Index([2, 3, 2, 1], name='my_index')
+        expected = pd.Index([2, 3, 1], name='my_index')
+        for level in 0, 'my_index', None:


can you integrete with the other tests of unique in indexes/common.py and/or tests/test_base.py

jreback · 2017-10-31T01:35:32Z

pandas/tests/indexes/test_multi.py

@@ -2269,6 +2271,20 @@ def test_unique(self):
        exp = pd.MultiIndex.from_arrays([['a'], ['a']])
        tm.assert_index_equal(res, exp)

+        # GH #17896 - with level= argument


try with named level, try on an already unique level as well. ideally even more corner cases.

make this a separate test and parametrize

jreback · 2017-11-11T11:42:03Z

doc/source/whatsnew/v0.22.0.txt

@@ -100,7 +100,7 @@ Indexing

 - Bug in :func:`PeriodIndex.truncate` which raises ``TypeError`` when ``PeriodIndex`` is monotonic (:issue:`17717`)
 - Bug in ``DataFrame.groupby`` where key as tuple in a ``MultiIndex`` were interpreted as a list of keys (:issue:`17979`)
-
+- :func:`MultiIndex.unique` now supports the ``level=`` argument (:issue:`17896`)


move to other enhancements

jreback · 2017-11-11T11:42:29Z

pandas/core/indexes/base.py

-    def unique(self):
+    def unique(self, level=None):
+        if level not in {0, self.name, None}:
+            raise ValueError("Level {} not found".format(level))


is the doc string for unique updated?

jreback · 2017-11-11T11:42:50Z

pandas/core/indexes/multi.py

@@ -896,20 +896,24 @@ def _get_level_values(self, level):
        Parameters
        ----------
        level : int level
+        unique : bool


add the default value in the doc string

jreback · 2017-11-11T11:43:59Z

pandas/core/indexes/multi.py

@@ -896,20 +896,24 @@ def _get_level_values(self, level):
        Parameters
        ----------
        level : int level
+        unique : bool


u can remove the versionadded tag here

jreback · 2017-11-11T11:46:20Z

pandas/tests/indexes/common.py

@@ -329,6 +329,25 @@ def test_duplicates(self, indices):
        assert not idx.is_unique
        assert idx.has_duplicates

+    def test_unique(self):
+        # GH 17896


really like to use the indices fixture here to test all Index types

It assigns no name to the indexes... shall I change it so it does?

you can try that

jreback · 2017-11-11T11:47:41Z

pandas/tests/indexes/test_multi.py

@@ -2269,6 +2271,20 @@ def test_unique(self):
        exp = pd.MultiIndex.from_arrays([['a'], ['a']])
        tm.assert_index_equal(res, exp)

+        # GH #17896 - with level= argument


make this a separate test and parametrize

jreback · 2017-11-11T11:48:58Z

pandas/tests/indexes/test_multi.py

+            tm.assert_index_equal(result, expected)
+
+            # With already unique level
+            mi = pd.MultiIndex.from_arrays([[1, 3, 2, 4], [1, 1, 1, 2]],


test with each level of the mi

jreback · 2017-11-11T11:49:34Z

pandas/tests/indexes/test_multi.py

+            tm.assert_index_equal(result, expected)
+
+    @pytest.mark.xfail(reason='GH 17924 (returns Int64Index with float data)')
+    def test_unique_with_nans(self):


remove this test

toobaz · 2017-11-12T21:08:45Z

The second commit changes the behavior of Index(., dtype='category').unique() to not change the order of categories (to the order of appearance). I know this is inconsistent with both Categorical.unique() and Series(., dtype='category').unique(), but I would rather change the latter two, because I don't see the point of unique() changing the categories at all.

If instead the current behavior is preferred, that commit can be dropped, and I will just need to exclude the category case from this test - because drop_duplicates and unique currently give different results.

jreback · 2017-11-12T21:12:06Z

but I would rather change the latter two, because I don't see the point of unique() changing the categories at all.

how did this come up? why do you think that the consistency should diverge here?

toobaz · 2017-11-12T21:16:50Z

how did this come up?

My new test compares drop_duplicates with unique, which differ for category, precisely because the categories change. But my argument is clearly not "let's save the test", it is "why should an operation which clearly doesn't change the set of distinct values affect the categories"?

why do you think that the consistency should diverge here?

I'm not in favor of breaking consistency (between Index, Categorical and Series), I would rather change them all.

jreback · 2017-11-12T21:53:56Z

@jorisvandenbossche

toobaz · 2017-11-14T21:48:52Z

The behavior of Categorical.unique() and friends (Series, Index) is probably worth discussing separately and fixing all together, so I created #18291, and changed the problematic test in this PR so it temporarily skips any CategoricalIndex.

toobaz · 2017-11-15T23:35:28Z

( @jreback : ping)

jorisvandenbossche · 2017-11-15T23:53:24Z

Will take a look at this tomorrow!

jreback · 2017-11-15T23:52:54Z

pandas/core/indexes/base.py

+        level : int or str, optional, default None
+            only return values from specified level (for MultiIndex)
+
+            .. versionadded:: 0.21.0


jreback · 2017-11-15T23:53:52Z

pandas/tests/indexes/common.py

+            with tm.assert_raises_regex(ValueError, msg):
+                indices.unique(level=level)
+
+    def test_unique_na(self, indices):


you are not using indices here, so don't add it as an argument

jorisvandenbossche

Looks good in general!
Added a bunch of minor comments

jorisvandenbossche · 2017-11-16T08:16:38Z

doc/source/whatsnew/v0.22.0.txt

@@ -24,6 +24,7 @@ Other Enhancements

 - Better support for :func:`Dataframe.style.to_excel` output with the ``xlsxwriter`` engine. (:issue:`16149`)
 - :func:`pandas.tseries.frequencies.to_offset` now accepts leading '+' signs e.g. '+1h'. (:issue:`18171`)
+- :func:`MultiIndex.unique` now supports the ``level=`` argument (:issue:`17896`)


Can you add briefly what it does, something like ".. to get the unique values of a single index level" ?

jorisvandenbossche · 2017-11-16T08:18:20Z

pandas/core/indexes/category.py

@@ -361,7 +361,9 @@ def is_monotonic_decreasing(self):
        return Index(self.codes).is_monotonic_decreasing

    @Appender(base._shared_docs['unique'] % _index_doc_kwargs)


Should this be the shared docs of 'index_unique' ?

jorisvandenbossche · 2017-11-16T08:18:53Z

pandas/core/indexes/base.py

+        Series.unique
+        """)
+
+    @Appender(base._shared_docs['index_unique'] % _index_doc_kwargs)


I don't think the _index_doc_kwargs are doing something here ?

No, you're right. But it was already the case, so I thought it was a choice of consistency ("you don't need to change this line if you change the docs making the interpolation meaningful"). Shall I remove it?

jorisvandenbossche · 2017-11-16T08:21:01Z

pandas/core/indexes/base.py

@@ -3757,8 +3757,32 @@ def drop(self, labels, errors='raise'):
            indexer = indexer[~mask]
        return self.delete(indexer)

-    @Appender(base._shared_docs['unique'] % _index_doc_kwargs)
-    def unique(self):
+    base._shared_docs['index_unique'] = (


I think this can be in _index_shared_docs instead of base._shared_docs ? (because base are the ones shared with series)

jorisvandenbossche · 2017-11-16T08:21:28Z

pandas/core/indexes/base.py

+        Parameters
+        ----------
+        level : int or str, optional, default None
+            only return values from specified level (for MultiIndex)


Start sentence with capital letter

jorisvandenbossche · 2017-11-16T08:28:06Z

pandas/core/indexes/multi.py

@@ -943,6 +947,15 @@ def get_level_values(self, level):
        values = self._get_level_values(level)
        return values

+    @Appender(base._shared_docs['index_unique'] % _index_doc_kwargs)


base._shared_docs -> index_shared_docs

jorisvandenbossche · 2017-11-16T08:48:44Z

pandas/core/indexes/base.py

+    @Appender(base._shared_docs['index_unique'] % _index_doc_kwargs)
+    def unique(self, level=None):
+        if level not in {0, self.name, None}:
+            raise ValueError("Level {} not found".format(level))


I think we have _get_level_number for this?

Or rather _validate_index_level which is used in _get_level_number

jorisvandenbossche · 2017-11-16T08:52:19Z

pandas/tests/indexes/test_multi.py

@@ -963,19 +963,21 @@ def test_get_level_values(self):
        exp = CategoricalIndex([1, 2, 3, 1, 2, 3])
        tm.assert_index_equal(index.get_level_values(1), exp)

-    def test_get_level_values_na(self):
+    @pytest.mark.xfail(reason='GH 17924 (returns Int64Index with float data)')


Why do we xfail this? (I mean, why don't we keep asserting for now that it is float)

The assertions compare a correctly built index (float64 data in Float64Index) with an invalid index (float64 data in Int64Index, due to #17924 ). Maybe I'm missing something, but it's not obvious to me what we would assert - plus, I see it as an added value to xfail for a buggy behavior.

jreback · 2017-11-19T16:20:34Z

needs a rebase

jorisvandenbossche

Last minor comments, otherwise looks good!

jorisvandenbossche · 2017-11-19T20:45:02Z

pandas/core/indexes/category.py

+    @Appender(_index_shared_docs['index_unique'] % _index_doc_kwargs)
+    def unique(self, level=None):
+        if level not in {0, self.name, None}:
+            raise ValueError("Level {} not found".format(level))


Use here _validate_index_level as well?

jorisvandenbossche · 2017-11-19T20:45:36Z

pandas/tests/indexes/test_multi.py

@@ -963,19 +963,21 @@ def test_get_level_values(self):
        exp = CategoricalIndex([1, 2, 3, 1, 2, 3])
        tm.assert_index_equal(index.get_level_values(1), exp)

-    def test_get_level_values_na(self):
+    @pytest.mark.xfail(reason='GH 17924 (returns Int64Index with float data)')


closes pandas-dev#17896

toobaz · 2017-11-20T07:29:43Z

ping

jorisvandenbossche · 2017-11-20T07:33:05Z

Thanks!

jreback requested changes Oct 16, 2017

View reviewed changes

jreback added the MultiIndex label Oct 16, 2017

toobaz force-pushed the get_level_values_unique branch from 57aa7e6 to 8a69543 Compare October 16, 2017 18:55

jschendel reviewed Oct 16, 2017

View reviewed changes

toobaz force-pushed the get_level_values_unique branch 4 times, most recently from e5a4635 to 3617e2a Compare October 17, 2017 11:57

jreback reviewed Oct 17, 2017

View reviewed changes

jorisvandenbossche reviewed Oct 18, 2017

View reviewed changes

toobaz mentioned this pull request Oct 19, 2017

MultiIndex.get_leves_values() returns inconsistent Index if there are NaNs #17924

Closed

toobaz force-pushed the get_level_values_unique branch 2 times, most recently from a07e2d8 to f0f7874 Compare October 30, 2017 07:34

jreback requested changes Oct 31, 2017

View reviewed changes

toobaz force-pushed the get_level_values_unique branch from f0f7874 to 284649a Compare November 11, 2017 08:22

jreback requested changes Nov 11, 2017

View reviewed changes

toobaz force-pushed the get_level_values_unique branch 3 times, most recently from 103d192 to d5f4324 Compare November 12, 2017 15:13

toobaz changed the title ~~API: add "unique=" argument to MultiIndex.get_level_values()~~ API: add "level=" argument to MultiIndex.unique() Nov 13, 2017

toobaz force-pushed the get_level_values_unique branch from d5f4324 to 861867c Compare November 14, 2017 20:51

toobaz mentioned this pull request Nov 14, 2017

Any categorical dtype object's .unique() changes categories #18291

Closed

jreback requested changes Nov 15, 2017

View reviewed changes

jreback added the API Design label Nov 15, 2017

jorisvandenbossche reviewed Nov 16, 2017

View reviewed changes

toobaz force-pushed the get_level_values_unique branch 3 times, most recently from fbf9eff to 337e942 Compare November 18, 2017 10:03

toobaz force-pushed the get_level_values_unique branch from 337e942 to 50f199d Compare November 19, 2017 16:31

jorisvandenbossche reviewed Nov 19, 2017

View reviewed changes

API: add "level=" argument to MultiIndex.unique()

feb65ed

closes pandas-dev#17896

toobaz force-pushed the get_level_values_unique branch from 50f199d to feb65ed Compare November 19, 2017 23:33

jorisvandenbossche approved these changes Nov 20, 2017

View reviewed changes

jorisvandenbossche merged commit 3b05a60 into pandas-dev:master Nov 20, 2017

toobaz deleted the get_level_values_unique branch November 20, 2017 08:11

		@@ -361,7 +361,9 @@ def is_monotonic_decreasing(self):
		return Index(self.codes).is_monotonic_decreasing

		@Appender(base._shared_docs['unique'] % _index_doc_kwargs)

API: add "level=" argument to MultiIndex.unique() #17897

API: add "level=" argument to MultiIndex.unique() #17897

Conversation

toobaz commented Oct 16, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

toobaz commented Oct 16, 2017

toobaz commented Oct 16, 2017

jreback commented Oct 16, 2017

toobaz commented Oct 16, 2017

codecov bot commented Oct 16, 2017

Codecov Report

codecov bot commented Oct 16, 2017 • edited Loading

Codecov Report

Choose a reason for hiding this comment

toobaz commented Oct 16, 2017

toobaz commented Oct 17, 2017

jorisvandenbossche commented Oct 17, 2017

jorisvandenbossche commented Oct 17, 2017 • edited Loading

toobaz commented Oct 17, 2017

jreback commented Oct 17, 2017

toobaz commented Oct 17, 2017

jreback Oct 17, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

toobaz commented Oct 30, 2017

jreback commented Oct 31, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

toobaz Nov 11, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

toobaz commented Nov 12, 2017

jreback commented Nov 12, 2017

toobaz commented Nov 12, 2017

jreback commented Nov 12, 2017

toobaz commented Nov 14, 2017

toobaz commented Nov 15, 2017

jorisvandenbossche commented Nov 15, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jorisvandenbossche left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

toobaz Nov 18, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

codecov bot commented Oct 16, 2017 •

edited

Loading

jorisvandenbossche commented Oct 17, 2017 •

edited

Loading

jreback Oct 17, 2017 •

edited

Loading

toobaz Nov 11, 2017 •

edited

Loading

toobaz Nov 18, 2017 •

edited

Loading