[Good first issue] TST: Disallow bare pytest.raises #30999

ShaharNaveh · 2020-01-14T12:17:56Z

End users rely on error messages for their debugging purposes. Thus, it is important that we make sure that the correct error messages are surfaced depending on the error triggered.

The core idea is to convert this:

with pytest.raises(klass):
    # Some code that raise an error

To this:

with pytest.raises(klass, match=msg):
    # Some code that raise an error

You can read more about pytest.raises here.

Side note:

In case that the raised error message is an external error message (meaning that's not pandas specific), you should use the external_error_raised instead of pytest.raises.

the usage of external_error_raised is exactly like pytest.raises the only difference is that you don't pass in the match argument.

For example:

import pandas._testing as tm

def test_foo():
    with tm.external_error_raised(ValueError):
        raise ValueError("foo")

Keynotes:

Don't forget to link this issue in your PR, paste this

https://github.com/pandas-dev/pandas/issues/30999

in your PR.

Please comment what you are planning to work on, so we won't do double the work (no need to mention me, you can just declare what you are planning to work on, just remember to check if something is already taken).
If a file/files that should be marked as "done" (as if there is no more work to do), isn't marked as "done", please comment letting me know about that (And mentioning me by putting @MomIsBestFriend at the comment's body, so I'll know where to look).

To generate the full list yourself, you can add:

    -   id: unwanted-patterns-bare-pytest-raises
        name: Check for use of bare use of pytest raises
        language: python
        entry: python scripts/validate_unwanted_patterns.py --validation-type="bare_pytest_raises"
        types: [python]
        files: ^pandas/tests/
        exclude: ^pandas/tests/extension

to .pre-commit-config.yaml in the - repo: local section, and then run

pre-commit run unwanted-patterns-bare-pytest-raises --all-files.

The current list is:

NOTE:

The list may change as files are moved/renamed constantly.

Took pretty much everything from #23922, that was originally opened by @gfyoung.

The text was updated successfully, but these errors were encountered:

ShaharNaveh · 2020-01-14T12:24:24Z

I'll take:

pandas/tests/test_common.py
pandas/tests/test_downstream.py
pandas/tests/test_errors.py
pandas/tests/test_lib.py
pandas/tests/test_take.py
pandas/tests/internals/test_internals.py
pandas/tests/window/test_rolling.py

gdex1 · 2020-01-14T13:25:44Z

I will begin working on:

pandas/tests/arithmetic/test_numeric.py
pandas/tests/arithmetic/test_object.py
pandas/tests/arithmetic/test_period.py
pandas/tests/arithmetic/test_timedelta64.py
pandas/tests/arrays/interval/test_interval.py

ShaharNaveh · 2020-01-14T13:30:33Z

@gdex1 I hope this will help you :)

(The numbers represents line number)

pandas/tests/arithmetic/test_numeric.py:138
pandas/tests/arithmetic/test_numeric.py:141
pandas/tests/arithmetic/test_numeric.py:190
pandas/tests/arithmetic/test_numeric.py:208
pandas/tests/arithmetic/test_numeric.py:210
pandas/tests/arithmetic/test_numeric.py:212
pandas/tests/arithmetic/test_numeric.py:214
pandas/tests/arithmetic/test_numeric.py:232
pandas/tests/arithmetic/test_numeric.py:234
pandas/tests/arithmetic/test_numeric.py:236
pandas/tests/arithmetic/test_numeric.py:238
pandas/tests/arithmetic/test_numeric.py:519
pandas/tests/arithmetic/test_numeric.py:610
pandas/tests/arithmetic/test_numeric.py:615
pandas/tests/arithmetic/test_numeric.py:617
pandas/tests/arithmetic/test_numeric.py:795
pandas/tests/arithmetic/test_numeric.py:798
pandas/tests/arithmetic/test_numeric.py:819

pandas/tests/arithmetic/test_object.py:140
pandas/tests/arithmetic/test_object.py:152
pandas/tests/arithmetic/test_object.py:154
pandas/tests/arithmetic/test_object.py:278
pandas/tests/arithmetic/test_object.py:280
pandas/tests/arithmetic/test_object.py:282
pandas/tests/arithmetic/test_object.py:284
pandas/tests/arithmetic/test_object.py:298
pandas/tests/arithmetic/test_object.py:301
pandas/tests/arithmetic/test_object.py:315
pandas/tests/arithmetic/test_object.py:318

pandas/tests/arithmetic/test_timedelta64.py:51
pandas/tests/arithmetic/test_timedelta64.py:445
pandas/tests/arithmetic/test_timedelta64.py:607
pandas/tests/arithmetic/test_timedelta64.py:609
pandas/tests/arithmetic/test_timedelta64.py:703
pandas/tests/arithmetic/test_timedelta64.py:705
pandas/tests/arithmetic/test_timedelta64.py:707
pandas/tests/arithmetic/test_timedelta64.py:709
pandas/tests/arithmetic/test_timedelta64.py:741
pandas/tests/arithmetic/test_timedelta64.py:743
pandas/tests/arithmetic/test_timedelta64.py:960
pandas/tests/arithmetic/test_timedelta64.py:972
pandas/tests/arithmetic/test_timedelta64.py:1028
pandas/tests/arithmetic/test_timedelta64.py:1037
pandas/tests/arithmetic/test_timedelta64.py:1039
pandas/tests/arithmetic/test_timedelta64.py:1502
pandas/tests/arithmetic/test_timedelta64.py:1505
pandas/tests/arithmetic/test_timedelta64.py:1508
pandas/tests/arithmetic/test_timedelta64.py:1511
pandas/tests/arithmetic/test_timedelta64.py:1536
pandas/tests/arithmetic/test_timedelta64.py:1591
pandas/tests/arithmetic/test_timedelta64.py:1783
pandas/tests/arithmetic/test_timedelta64.py:1785
pandas/tests/arithmetic/test_timedelta64.py:1911
pandas/tests/arithmetic/test_timedelta64.py:1960
pandas/tests/arithmetic/test_timedelta64.py:1962
pandas/tests/arithmetic/test_timedelta64.py:1968

pandas/tests/arrays/interval/test_interval.py:155

ShaharNaveh · 2020-01-14T19:09:00Z

@gfyoung the list wasn't generated by grep -r -e "pytest.raises([a-zA-Z]*)" pandas/tests -l in fact, it was generated by the script in #30755 (a validation type called bare_pytest_raises), I will put instructions at the issue body, once it gets merged 😄

shubchat · 2020-01-14T19:42:23Z

@MomIsBestFriend I will help with :
pandas/tests/base/test_constructors.py
pandas/tests/base/test_ops.py

DylanBrdt · 2020-01-15T01:23:18Z

I can take care of these:
@MomIsBestFriend

pandas/tests/io/test_html.py
pandas/tests/io/test_parquet.py
pandas/tests/io/test_sql.py
pandas/tests/io/test_stata.py
pandas/tests/plotting/test_backend.py
pandas/tests/plotting/test_boxplot_method.py
pandas/tests/plotting/test_frame.py
pandas/tests/plotting/test_hist_method.py
pandas/tests/plotting/test_series.py
pandas/tests/reductions/test_reductions.py

…pplicable lines.

jorisvandenbossche · 2020-01-15T07:40:05Z

@MomIsBestFriend there was quite some discussion in #23922 about to go about this. Because to repeat as I said there: I don't think we should "blindly" assert all error messages.

Some things that were said in that thread: limit it to internal error messages, limit the match to a few key words of the message, avoid complicated patterns.

Also, I think asserting error messages should go hand in hand with actually checking if it is a good, clear error message, and potentially improving this.

It might be good to distill a list of attention points from the discussion in the other issue to put here.

ShaharNaveh · 2020-01-15T22:14:35Z

@jorisvandenbossche

@MomIsBestFriend there was quite some discussion in #23922 about to go about this. Because to repeat as I said there: I don't think we should "blindly" assert all error messages.

I completely agree, but the problem is that newcomers don't know what error messages to assert and what error messages not to assert, if we somehow define rules on what error messages to assert and what not to assert, and at the same time keeping this issue "beginner friendly", it will be great (IMO).

Also, if we plan to enforce this in the CI we need to somehow mark what bare pytest raises are "bare" on purpose (IMO comment with the style of isort: skip is enough) , and also so other people will know that a particular bare pytest raise is bare on purpose.

Some things that were said in that thread: limit it to internal error messages, limit the match to a few key words of the message, avoid complicated patterns.

I don't see why we wouldn't want to test internal error messages, can you please elaborate even more?

I see the point that you pointed out in #23922 (comment), and I'm +1 on that, but I'm +2 (if that make any sense) on #23922 (comment) and #23922 (comment) because IMO the benefit is larger than the cost.

Also, I think asserting error messages should go hand in hand with actually checking if it is a good, clear error message, and potentially improving this.

Absolutely agree.

It might be good to distill a list of attention points from the discussion in the other issue to put here.

I have read the conversation at #23922, but I didn't saw anything that IMO is worth putting as a "note" in the issue's body, can you please point out things I missed?

gfyoung · 2020-01-15T23:00:07Z

I have read the conversation at #23922, but I didn't saw anything that IMO is worth putting as a "note" in the issue's body, can you please point out things I missed?

I don't see much else to add from that issue either.

I completely agree, but the problem is that newcomers don't know what error messages to assert and what error messages not to assert, if we somehow define rules on what error messages to assert and what not to assert, and at the same time keeping this issue "beginner friendly", it will be great (IMO).

Also, if we plan to enforce this in the CI we need to somehow mark what bare pytest raises are "bare" on purpose (IMO comment with the style of isort: skip is enough) , and also so other people will know that a particular bare pytest raise is bare on purpose.

These are reasons in part why picking and choosing which to test and which not to test is not the direction I would prefer. I would also add that we do sometimes check error message strings in except blocks, so good error messages also benefit us during development.

Also, if these "internal" messages aren't that important, why do we have an error message in the first place? I would then just create a helper that then asserts the message is empty.

jorisvandenbossche · 2020-01-16T08:46:09Z

I don't see why we wouldn't want to test internal error messages, can you please elaborate even more?

So I said "limit to internal error messages", while "internal" can be a bit ambiguous... I meant: error messages that originate from pandas itself, and of course we want to test those. But so I meant that we (IMO) shouldn't test too much external error messages, meaning: messages coming from eg numpy or other libraries. Numpy can change those, and then our tests start failing due to a cosmetic change in numpy (and this is not hypothetical, it happened just last week I think).

Now, I used "internal" in a different context in #30998 (comment). There, I meant as an internal, developer oriented error message that should never be raised to the user. IMO, those are not important to test exactly with the error message.

I see the point that you pointed out in #23922 (comment), and I'm +1 on that, but I'm +2 (if that make any sense) on #23922 (comment) and #23922 (comment) because IMO the benefit is larger than the cost.

Let's put @simonjayhawkins's comment that you link to here:

I am working on the assumption, maybe incorrectly, that it will be beneficial to

identify tests that can be parametrized

identify tests that should be split

better understanding of the failure mode tested

indirectly add more documentation to the tests

identify where error messages could be more consistent

identify tests that are redundant

help improve error messages

identify tests that are currently passing for the wrong reason.

That are all useful things, I fully agree. But that is not simple, and if we want to get those things out of this issue, then this issue is not for beginners. Of course, beginners don't need to do all of those things at once, but I still have the feeling that those PRs adding asserts are often rather close to "blindly adding the current error message to the pytest.raises call" without going any further (the above points).

Also, if the above points is what makes this exercise useful, it are more concrete instructions about this that is useful to put at the top of this issue, I think.

To be clear, I am all for better error messages and better tests asserting we have and keep those error messages good. But we also have limited time, and each PR requires time and effort to do and to review, and the question is where effort is best spent.
IMO, it would be more useful instead to focus on "fix bare pytest raises" rather to focus on "improve error messages" (and while doing this, better test them).

gfyoung · 2020-01-16T08:59:17Z

Also, if the above points is what makes this exercise useful, it are more concrete instructions about this that is useful to put at the top of this issue, I think.

It might make sense to create a larger issue to track these (other issues worth including in such an issue are #19159 and #21575).

This part in itself is self-contained and is very approachable for beginners.

jorisvandenbossche · 2020-01-16T09:01:53Z

@gfyoung how are those issues you link related to this discussion?

gfyoung · 2020-01-16T09:05:14Z

They relate to the comment that you explicitly introduced from @simonjayhawkins

bashtage · 2020-01-16T12:10:58Z

#31072 contains the one missing match in stata.py

ShaharNaveh · 2020-01-17T01:22:56Z

As saying here #31091 (comment) I'm with @jorisvandenbossche's idea, that we won't test error messages from external packages, Any ideas on how to mark those?

gfyoung · 2020-01-17T01:38:06Z

If we really don't want to test certain error messages (I could go either way on external ones to be fair), I think we should just create a helper function like this:

def external_error_raised(expected_exception):
   return pytest.raises(expected_exception, match=None)

This will make it clear to our future selves that this is a non-pandas error, and the match=None serves to appease any linting check we develop for bare pytest raises.

ShaharNaveh · 2020-01-17T08:13:21Z

If we really don't want to test certain error messages (I could go either way on external ones to be fair), I think we should just create a helper function like this:
def external_error_raised(expected_exception):
   return pytest.raises(expected_exception, match=None)
This will make it clear to our future selves that this is a non-pandas error, and the match=None serves to appease any linting check we develop for bare pytest raises.

+1 on that.

I really like that idea, can we make it a convention for our tests?

That if a function is testing if a function/method is raising an error, and the error is an external error, we simply put match=None in the "pytest.raises```.

can we make it a convention for our tests?

By that I mean putting a section on in the Contributing guide.

moink · 2020-12-30T10:04:58Z

I will take:

pandas/tests/reshape/test_get_dummies.py
pandas/tests/reshape/test_union_categoricals.py

moink · 2020-12-30T11:10:12Z

I will take:
pandas/tests/window/moments/test_moments_ewm.py
pandas/tests/window/test_apply.py

moink · 2020-12-30T11:35:01Z

I will take:

pandas/tests/dtypes/test_inference.py
pandas/tests/libs/test_hashtable.py
pandas/tests/resample/test_resampler_grouper.py

moink · 2020-12-30T13:44:35Z

Done:
pandas/tests/reshape/test_get_dummies.py
pandas/tests/reshape/test_union_categoricals.py
pandas/tests/dtypes/test_inference.py
pandas/tests/libs/test_hashtable.py
pandas/tests/resample/test_resampler_grouper.py

moink · 2020-12-30T14:12:01Z

Done:
pandas/tests/window/moments/test_moments_ewm.py
pandas/tests/window/test_apply.py

moink · 2020-12-30T17:33:03Z

I will take

pandas/tests/indexing/multiindex/test_partial.py
pandas/tests/indexing/test_coercion.py

moink · 2020-12-31T11:53:54Z

I will take
pandas/tests/arrays/boolean/test_arithmetic.py

moink · 2020-12-31T15:08:25Z

I will make an attempt at:

pandas/tests/series/apply/test_series_apply.py
pandas/tests/series/test_ufunc.py

and see what people think

moink · 2020-12-31T19:49:00Z

Done:
pandas/tests/series/apply/test_series_apply.py
pandas/tests/series/test_ufunc.py
pandas/tests/indexing/multiindex/test_partial.py
pandas/tests/indexing/test_coercion.py
pandas/tests/indexes/multi/test_indexing.py
pandas/tests/indexes/multi/test_setops.py
pandas/tests/indexes/period/test_indexing.py
pandas/tests/indexes/test_common.py
pandas/tests/indexes/test_numpy_compat.py

moink · 2020-12-31T19:53:17Z

I will take
pandas/tests/io/json/test_normalize.py

moink · 2020-12-31T20:28:50Z

I think I have handled all the easy-enough-to-handle instances of bare pytest.raise. There are still 15 left. Let me explain for each of them why I am not fixing them myself right now:

in pandas/tests/extension there are 12 spread across 6 files. If I understand the proposed linting rule, we will exclude these from the linting. It's a pretty complex inheritance hierarchy in there, and hard to tease out which tests are affected and restructure them to be able to pass the error message around to where they are actually used.
in pandas/tests/io/test_sql.py there are two, one in TestXMySQL.test_execute_fail and one in TestXMySQL.test_execute_closed_connection. I can't seem to figure out how to set up my local environment to get these tests to run rather than being skipped. Advice is welcome.
in pandas/tests/computation/test_compat.py there is 1, in test_invalid_numexpr_version. But the line in question only runs with a version of the numexpr library prior to 2.6.8 and I don't want to mess with my environment, because the last time I tried something similar I couldn't easily fix my environment and had to delete and recreate it. Again I would take advice on that.

I would say that this is no longer a "good first issue" because there are only complex instances left.

simonjayhawkins · 2020-12-31T20:36:47Z

@moink you could submit a draft PR and use match="^$" or match="kjkkakkdkskdkd" and get the current message from the ci logs

moink · 2020-12-31T20:40:57Z

@moink you could submit a draft PR and use match="^$" or match="kjkkakkdkskdkd" and get the current message from the ci logs

Ok thanks @simonjayhawkins I will do that. I thought about abusing the CI for this - if it's ok to do that then I will. I also didn't know that CI ran on draft PRs.

moink · 2021-01-01T12:15:45Z

I opened #38876 with the pytest.raises context manager commented out for three tests (in pandas/tests/io/test_sql.py and pandas/tests/computation/test_compat.py) and there weren't any errors in the CI. Is it possible that the conditions for running that code is also not satisfied in the CI? In which case what's the strategy - simply delete that part of the tests?

rhshadrach · 2021-01-02T13:10:11Z

@moink This should probably be handled on a case-by-case basis. I'd recommend searching for issues on these tests and creating them if none exist, then post references here.

ShaharNaveh added good first issue Code Style Code style, linting, code_checks Testing pandas testing functions or related to the test suite labels Jan 14, 2020

simonjayhawkins mentioned this issue Jan 14, 2020

TST: Disallow bare pytest.raises #23922

Closed

This was referenced Jan 14, 2020

TST: Insert 'match' to bare pytest raises #30997

Merged

TST: insert 'match' to bare pytest raises in pandas/tests/internals/ #30998

Merged

simonjayhawkins added this to the Contributions Welcome milestone Jan 14, 2020

ShaharNaveh mentioned this issue Jan 14, 2020

TST: bare pytest raises #31001

Merged

5 tasks

gfyoung pinned this issue Jan 14, 2020

DylanBrdt added a commit to DylanBrdt/pandas that referenced this issue Jan 15, 2020

Issue #pandas-dev#30999, Added match = msg as a second parameter in a…

bc5c6c4

…pplicable lines.

DylanBrdt mentioned this issue Jan 15, 2020

Disallow bare pytest.raises #31029

Closed

5 tasks

gdex1 mentioned this issue Jan 15, 2020

TST: Disallow bare pytest.raises #31045

Merged

5 tasks

gdex1 mentioned this issue Jan 16, 2020

TST: Remove bare pytest.raises #31079

Merged

5 tasks

MarcoGorelli mentioned this issue Dec 30, 2020

TST: Add hook for Disallow bare pytest.raises #38799

Merged

moink mentioned this issue Dec 30, 2020

TST: GH30999 Add match=msg to all pytest.raises in pandas/tests/reshape #38800

Merged

5 tasks

moink mentioned this issue Dec 30, 2020

TST: GH30999 add match=msg to all pytest.raises in pandas/tests/window #38804

Merged

5 tasks

moink mentioned this issue Dec 30, 2020

TST: GH30999 add match=msg to pytest.raises in modules with one simple instance each #38805

Merged

5 tasks

moink mentioned this issue Dec 30, 2020

Improve error message in Series.any and Series.all, when bool_only is passed and not level #38810

Closed

This was referenced Dec 30, 2020

TST GH30999 Change bare pytest.raises in pandas/tests/indexing to tm.external_error_raised jreback/pandas#18

Closed

TST: GH30999 Change all pytest.raises in pandas/tests/indexing to tm.external_error_raised #38825

Merged

moink mentioned this issue Dec 31, 2020

TST: GH30999 address all bare pytest.raises in pandas/tests/arrays/boolean/test_arithmetic.py #38849

Merged

5 tasks

moink mentioned this issue Dec 31, 2020

TST: GH30999 address all bare pytest.raises in pandas/tests/series and add EMPTY_STRING_PATTERN to tm #38855

Merged

5 tasks

moink mentioned this issue Dec 31, 2020

TST: GH30999 add match=msg to 2 pytest.raises in pandas/tests/io/json/test_normalize.py #38864

Merged

5 tasks

moink mentioned this issue Jan 1, 2021

TST: GH30999 TESTING PR do not merge or review #38876

Closed

5 tasks

This was referenced Jan 3, 2021

TST: GH30999 Add placeholder messages to pandas/tests/io/test_sql.py and remove test for numexpr < 2.6.8 #38920

Merged

TST: update pre-commit config to only exclude extension from bare pytest.raises check #38973

Merged

jorisvandenbossche closed this as completed in #38973 Jan 5, 2021

Aloqeely mentioned this issue Apr 17, 2024

TST: Disallow bare tm.assert_produces_warning #58290

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Good first issue] TST: Disallow bare pytest.raises #30999

[Good first issue] TST: Disallow bare pytest.raises #30999

ShaharNaveh commented Jan 14, 2020 •

edited by MarcoGorelli

Loading

ShaharNaveh commented Jan 14, 2020 •

edited

Loading

gdex1 commented Jan 14, 2020

ShaharNaveh commented Jan 14, 2020 •

edited

Loading

ShaharNaveh commented Jan 14, 2020 •

edited

Loading

shubchat commented Jan 14, 2020

DylanBrdt commented Jan 15, 2020

jorisvandenbossche commented Jan 15, 2020

ShaharNaveh commented Jan 15, 2020 •

edited

Loading

gfyoung commented Jan 15, 2020 •

edited

Loading

jorisvandenbossche commented Jan 16, 2020

gfyoung commented Jan 16, 2020 •

edited

Loading

jorisvandenbossche commented Jan 16, 2020

gfyoung commented Jan 16, 2020 •

edited

Loading

bashtage commented Jan 16, 2020

ShaharNaveh commented Jan 17, 2020

gfyoung commented Jan 17, 2020 •

edited

Loading

ShaharNaveh commented Jan 17, 2020 •

edited

Loading

moink commented Dec 30, 2020

moink commented Dec 30, 2020

moink commented Dec 30, 2020

moink commented Dec 30, 2020

moink commented Dec 30, 2020

moink commented Dec 30, 2020

moink commented Dec 31, 2020

moink commented Dec 31, 2020

moink commented Dec 31, 2020

moink commented Dec 31, 2020

moink commented Dec 31, 2020

simonjayhawkins commented Dec 31, 2020

moink commented Dec 31, 2020 •

edited

Loading

moink commented Jan 1, 2021

rhshadrach commented Jan 2, 2021

[Good first issue] TST: Disallow bare pytest.raises #30999

[Good first issue] TST: Disallow bare pytest.raises #30999

Comments

ShaharNaveh commented Jan 14, 2020 • edited by MarcoGorelli Loading

Side note:

Keynotes:

The current list is:

NOTE:

ShaharNaveh commented Jan 14, 2020 • edited Loading

gdex1 commented Jan 14, 2020

ShaharNaveh commented Jan 14, 2020 • edited Loading

ShaharNaveh commented Jan 14, 2020 • edited Loading

shubchat commented Jan 14, 2020

DylanBrdt commented Jan 15, 2020

jorisvandenbossche commented Jan 15, 2020

ShaharNaveh commented Jan 15, 2020 • edited Loading

gfyoung commented Jan 15, 2020 • edited Loading

jorisvandenbossche commented Jan 16, 2020

gfyoung commented Jan 16, 2020 • edited Loading

jorisvandenbossche commented Jan 16, 2020

gfyoung commented Jan 16, 2020 • edited Loading

bashtage commented Jan 16, 2020

ShaharNaveh commented Jan 17, 2020

gfyoung commented Jan 17, 2020 • edited Loading

ShaharNaveh commented Jan 17, 2020 • edited Loading

moink commented Dec 30, 2020

moink commented Dec 30, 2020

moink commented Dec 30, 2020

moink commented Dec 30, 2020

moink commented Dec 30, 2020

moink commented Dec 30, 2020

moink commented Dec 31, 2020

moink commented Dec 31, 2020

moink commented Dec 31, 2020

moink commented Dec 31, 2020

moink commented Dec 31, 2020

simonjayhawkins commented Dec 31, 2020

moink commented Dec 31, 2020 • edited Loading

moink commented Jan 1, 2021

rhshadrach commented Jan 2, 2021

ShaharNaveh commented Jan 14, 2020 •

edited by MarcoGorelli

Loading

ShaharNaveh commented Jan 14, 2020 •

edited

Loading

ShaharNaveh commented Jan 14, 2020 •

edited

Loading

ShaharNaveh commented Jan 14, 2020 •

edited

Loading

ShaharNaveh commented Jan 15, 2020 •

edited

Loading

gfyoung commented Jan 15, 2020 •

edited

Loading

gfyoung commented Jan 16, 2020 •

edited

Loading

gfyoung commented Jan 16, 2020 •

edited

Loading

gfyoung commented Jan 17, 2020 •

edited

Loading

ShaharNaveh commented Jan 17, 2020 •

edited

Loading

moink commented Dec 31, 2020 •

edited

Loading