Adding test_isinstance_string_types, with asserts simply matching cur… #2256

rwgk · 2020-06-18T19:26:05Z

…rent behavior.

Basis for discussing actual desired behavior.

Background:

rwgk · 2020-07-22T22:20:48Z

@wjakob @YannickJadoul Request for Review

This PR has two commits:

d50fcad Adding tests for existing behavior. This is to establish a baseline, to more easily see how the behavior changes with the 2. Commit.
c78cc6a Makes pybind11::isinstance behavior compatible with native Python isinstance() behavior.

Commit 2. has a side-effect, that could be seen as desirable, or undesirable: it disables implicit decode when passing bytes to a unicode argument.

Note that Commit 2. also fixes #2198 (which is what got me started with this PR).

About naming: the meaning of the term str is highly ambiguous, and using it to explain is bound to be confusing.
Instead, I'm using the terms actual bytes and actual unicode, irrespective of the Python version.
I'm using the term "native name" for the name as used by the Python interpreter.

For Python 2:

actual bytes has the native names bytes and str.
actual unicode has the native name unicode.

For Python 3:

actual bytes has the native name bytes.
actual unicode has the native name str.

For pybind11, irrespective of the Python version:

actual bytes is pybind11::bytes.
actual unicode is pybind11::str.

The essential part of Commit 2. is a one-line insertion copied from @jagerman : 77059f0

The desired effect is that it makes isinstance<str> compatible native isinstance(actual_unicode). See the corresponding one-line change in test_pytypes.py.

But three other tests are affected.

In test_pytypes.py we now have:

with pytest.raises(TypeError):                                              
    m.pass_to_pybind11_unicode(actual_bytes)  # NO implicit decode

Before Commit 2. the function call succeeds, with implicit decoding. This behavior change would need to be added to the Release Notes.

Because of the behavior change, test_eval_file in test_eval.py breaks. It is easily fixed with the equivalent of six.ensure_text().
This test in test_stl.py fails:
```
assert m.func_with_string_or_vector_string_arg_overload('A') == 3  # returns 2 without the fix
```
The fix is a one-line change to list_caster in stl.h, which amounts to: don't convert a sequence object to a list if it is actual unicode or native str. To make that one-line change easy to read, I introduced a native_str alias in pytypes.h (this would need to be documented).

Is the behavior change good or bad?

My opinion: Good. "Explicit is better than implicit." for this case. It's easy to add .decode(), or six.ensure_text() if Python 2 compatibility matters. Also note:

Passing to std::string (and relatives) still supports passing actual bytes or actual unicode directly. With this PR, all choices are available: accept either, accept only actual bytes, accept only actual unicode.
The added explicit .decode() are compatible with pybind11 as-is, if it matters to some users that their code works with old and new versions of pybind11.
This PR works out nicely for both Python 2 and Python 3.

Detail: if accepted, I'd want to merge the commits separately, for the same reasons that I have them separately in this PR.

bstaletic · 2020-07-22T22:54:40Z

But three other tests are affected.

Are those affected on python3 as well as python2?

Because of the behavior change, test_eval_file in test_eval.py breaks. It is easily fixed with the equivalent of six.ensure_text().

Can you provide a link to ensure_text() and what it does?

The fix is a one-line change to list_caster in stl.h, which amounts to: don't convert a sequence object to a list if it is actual unicode or native str. To make that one-line change easy to read, I introduced a native_str alias in pytypes.h (this would need to be documented).

What is "native str" in this context? Do you mean unicode on py2 and str on py3? How is that different from what you have called "actual unicode"? Or do you mean bytes on py2 and str on py3?

rwgk · 2020-07-22T23:09:35Z

But three other tests are affected.

Are those affected on python3 as well as python2?

test_eval.py and test_stl.py were passing with Python 3, but failing with Python 2. My new test in test_pytypes.py is affected for both Python versions.
Good question, sorry I forgot to clarify.

Can you provide a link to ensure_text() and what it does?

https://pypi.org/project/six/
https://github.com/benjaminp/six/blob/c0be8815d13df45b6ae471c4c436cce8c192245d/six.py#L923

What is "native str" in this context? Do you mean unicode on py2 and str on py3? How is that different from what you have called "actual unicode"? Or do you mean bytes on py2 and str on py3?

The new pybind11::native_str is the C++ side equivalent of native str as seen in the interpreter, therefore depends on the Python version. Did you see the new code block in pytypes.h?

#if PY_MAJOR_VERSION < 3
using native_str = bytes;
#else
using native_str = str;
#endif

Note: pybind11::str is always actual_unicode.

bstaletic · 2020-07-22T23:55:16Z

Regarding "native str", is the proposed behaviour of list_caster correct? You're banning bytes and unicode on python2, but only unicode on python3.

rwgk · 2020-07-23T00:33:01Z

Regarding "native str", is the proposed behaviour of list_caster correct? You're banning bytes and unicode on python2, but only unicode on python3.

Good question again: I figured that was the original intention, to prevent accidental conversion of "regular" str literals to a list of integers. Thinking: with Python 3 it makes sense to allow bytes, with Python 2 not so much.

wjakob · 2020-07-23T08:56:42Z

include/pybind11/stl.h

@@ -144,7 +144,7 @@ template <typename Type, typename Value> struct list_caster {
    using value_conv = make_caster<Value>;

    bool load(handle src, bool convert) {
-        if (!isinstance<sequence>(src) || isinstance<str>(src))
+        if (!isinstance<sequence>(src) || isinstance<str>(src) || isinstance<native_str>(src))


redundant check on Python 3.x?

Yes, exactly.
I did it this way mostly because I thought it's the clearest way of putting the condition, for the purpose of this code review. ("optimize later")

To also answer @bstaletic question here:

I still don't understand. Why does it make sense to allow bytes on python3, but not on python2? I would understand, were pybind11 dealing in py::native_bytes and py::native_str everywhere. It isn't, so having py::native_str in this one place seems very surprising.

TL;DR: What would be the behavior that you prefer to see here?

With Python 2 the interpreter (!) will tell you bytes is str is True, therefore you cannot enable conversion of bytes to list without also enabling conversion of [Python 2 native str] to list. That's a feature you can only have with Python 3. — Another way to put it: do you NOT want to use the feature in Python 3 because you cannot have it in Python 2?

We can do anything else we want here, what you see is what I assumed was the original intent.
(At some point long time ago, when there was only Python 2, I had a similar problem and disabled str to list conversions to prevent confusing accidents.)
Once we are certain what we want, we could optimize, e.g. by putting the #ifdef here and not even having the native_str type.

TL;DR: What would be the behavior that you prefer to see here?

Either:

Ban everything that's string-like in the list_caster

Or allow bytes in both py2 and py3

With Python 2 the interpreter (!) will tell you bytes is str is True, therefore you cannot enable conversion of bytes to list without also enabling conversion of [Python 2 native str] to list.

Why is py2 str (or py2 bytes, but those are the exact same thing) to list problematic if py3 bytes to list isn't?

Another way to put it: do you NOT want to use the feature in Python 3 because you cannot have it in Python 2?

Rarely, but if it helps me reason about what is going on in the code, I see nothing wrong with that.

Ban everything that's string-like in the list_caster

That's current behavior. Two consequences:

Effectively you do not want to use a feature that's feasible with Python 3 because it's infeasible in Python 2.

Effectively a rejection of Fixes #1807: 2.3.0 regression: <class 'bytes'> -> std::vector<uint8_t> #2198.

Or allow bytes in both py2 and py3

That breaks the existing test in test_stl.py: assert m.func_with_string_or_vector_string_arg_overload('A') == 3
We'd have to change that to u'A', list('A'), or iter('A') to pass again.

The behavior currently implemented in this PR means:

If you care about Python 3 (and the future) only: you're fine!

If you still care about Python 2 even past EOL, you'll have to use explicit list(s) or iter(s) (which is also Python 3 compatible).

I feel that's the best compromise, but I'll go with the votes of the team.
@YannickJadoul and Wenzel, what are your votes on this specific list_caster question?

That breaks the existing test in test_stl.py: assert m.func_with_string_or_vector_string_arg_overload('A') == 3

Is this an actual concern, considering that this pull request already contains a breaking change.

That breaks the existing test in test_stl.py: assert m.func_with_string_or_vector_string_arg_overload('A') == 3

Is this an actual concern, considering that this pull request already contains a breaking change.

I'd say so, I think it's worth getting each of the 3 questions settled in the best way possible.

The only fully intentional change is for isinstance<str>. We could preserve the behaviors for the other 2, although I've not looked into what it would take to preserve the implicit bytes to actual unicode conversions. I'm waiting for Yannick's and Wenzel's takes before investing time there.

wjakob · 2020-07-23T08:57:16Z

include/pybind11/pytypes.h

@@ -950,6 +950,8 @@ inline namespace literals {
 inline str operator"" _s(const char *s, size_t size) { return {s, size}; }
 }

+template <> inline bool isinstance<str>(handle obj) { return PyUnicode_Check(obj.ptr()); }


This will change the behavior of pybind11, no?

Yes. I wrote the long Request for Review comment for exactly this reason. I'm pointing this out in at the beginning ("desirable/undesirable") and at the end ("good or bad?"), hoping to provide a start for collectively reasoning out if, how, and when we want to change the behaviors.

There are actually "3 and a half" behaviors that are (unfortunately) convoluted:

isinstance (reminder: str is always actual unicode in pybind11), keep or match native?

implicit decode when passing bytes to pybind11::str, keep or disable?

what do we want to do about bytes to list conversions in A. Python 2, B. Python 3?

What would be your preferred answers for these 3 cases independently?
I guess we can always engineer a way to achieve any combination of preferred answers, even making the changes independently in multiple pybind11 releases.

wjakob · 2020-07-23T09:00:52Z

I'm generally okay with these changes, but compatibility is going to be problem. Disabling an implicit bytes -> unicode conversion will break packages that depend on this behavior. Given that we have chosen to adopt SemVer, it seems to me that this kind of change will necessarily fall in the category "postpone to next major version bump".

bstaletic · 2020-07-23T11:47:01Z

Regarding "native str", is the proposed behaviour of list_caster correct? You're banning bytes and unicode on python2, but only unicode on python3.

Good question again: I figured that was the original intention, to prevent accidental conversion of "regular" str literals to a list of integers. Thinking: with Python 3 it makes sense to allow bytes, with Python 2 not so much.

I still don't understand. Why does it make sense to allow bytes on python3, but not on python2? I would understand, were pybind11 dealing in py::native_bytes and py::native_str everywhere. It isn't, so having py::native_str in this one place seems very surprising.

rwgk · 2020-07-23T16:50:03Z

Regarding "native str", is the proposed behaviour of list_caster correct? You're banning bytes and unicode on python2, but only unicode on python3.

Good question again: I figured that was the original intention, to prevent accidental conversion of "regular" str literals to a list of integers. Thinking: with Python 3 it makes sense to allow bytes, with Python 2 not so much.

I still don't understand. Why does it make sense to allow bytes on python3, but not on python2? I would understand, were pybind11 dealing in py::native_bytes and py::native_str everywhere. It isn't, so having py::native_str in this one place seems very surprising.

Answer under #2256 (comment)

YannickJadoul

To me, this PR makes sense from the Python 3 perspective. I had no idea bytes would convert to py::str. And py::isinstance<py:str> of a bytes object seems plain wrong?
Then again, why does the current implementation not do that?

Before continuing, let's put this straight: it's 2020 and Python 3 fixed string types. So I think Python 3 should be the standard and what guides development, while keeping Python 2 as sane as possible. (I think that's also what pybind11 has already been doing, actually; py::str being "actual unicode" in Ralf's terminology and py::bytes being "actual bytes" match Python 3's names).

If anything, we should maybe clarify this by adding something to the docs. Some kind of "String types" section here: https://pybind11.readthedocs.io/en/stable/advanced/pycpp/object.html?

Another option would be to still allow for Python 2 str (so "actual bytes") to be converted to py::str, but ónly on Python 2? But then not in isinstance<py::str>, but with convert=True in the string caster.

Regarding "native str", is the proposed behaviour of list_caster correct? You're banning bytes and unicode on python2, but only unicode on python3.

Good question again: I figured that was the original intention, to prevent accidental conversion of "regular" str literals to a list of integers. Thinking: with Python 3 it makes sense to allow bytes, with Python 2 not so much.

I think I agree here. str is a very ambiguous type in Python 2 (being both a bytes-container as well as the default string type), so you want to be careful with converting that to a vector of bytes. On the other hand, Python 3 fixed this, doesn't confuse strings with plain bytes anymore, so we can allow Python 3's bytes to be nicely converted into a vector.
There's something to be said for consistency as well, but ... again, maybe this should just be clarified in some docs.

YannickJadoul · 2020-07-25T16:49:56Z

include/pybind11/pytypes.h

+#if PY_MAJOR_VERSION < 3
+using native_str = bytes;
+#else
+using native_str = str;
+#endif
+


We already have PYBIND11_STR_TYPE for that?

Ah, very good, thanks for pointing that out! I would never have guessed from the name what it does, but now I know :-)

If you/we want to provide this as API to pybind11 users, we should provide a typedef, though, rather than have them use this macro.
If so, I'm just not entirely convinced about native_str as a name (though I don't now, immediately have a better suggestion).

YannickJadoul · 2020-07-25T18:56:29Z

Then again, why does the current implementation not do that?

Let me answer my own question:

pybind11/include/pybind11/pytypes.h

Lines 888 to 890 in 7e0a4fb

    
           class str : public object { 
        
           public: 
        
               PYBIND11_OBJECT_CVT(str, object, detail::PyUnicode_Check_Permissive, raw_str)

So why not change str::check_ rather than the isinstance specialization?

rwgk · 2020-07-29T18:46:47Z

So why not change str::check_ rather than the isinstance specialization?

Jumping to my most important question first: what are my options for re-enabling the implicit conversion from py::bytes to py::str after replacing detail::PyUnicode_Check_Permissive with PyUnicode_Check?

Motivation for asking: I want to backtrack from making 3 behavior changes to only one. Concretely:

I want to fix isinstance<str> which is currently highly misleading (seems plain wrong to me).
I want to keep the existing implicit conversion from py::bytes to py::str (because Wenzel suggested that can only change with a version change) but how?
I want to keep the existing behavior for the list_caster, which is super easy to tweak that way.

Secondary observations & questions:

I tried @YannickJadoul 's suggestion (as I understood it), by removing the isinstance<str> specialization and changing

PYBIND11_OBJECT_CVT(str, object, detail::PyUnicode_Check_Permissive, raw_str)

to

PYBIND11_OBJECT_CVT(str, object, PyUnicode_Check, raw_str)

Python 3: All tests pass, with the rest of this PR as-is. (To clarify: NO implicit bytes-str conversion, as before.)

Python 2: Only one test failed: test_pytypes.py test_constructors(). Fails for str. Looking at it, I'm confused why it even works with Python 2 pybind11 as-is. I'll work on trying to understand.

While trying ideas for fixes I stumbled over another problem, for which I created a mock PR to easily show: #2340
The question there: Are we looking at that as a bug or feature?

bstaletic · 2020-07-31T15:01:27Z

Motivation for asking: I want to backtrack from making 3 behavior changes to only one. Concretely:

I want to fix isinstance which is currently highly misleading (seems plain wrong to me).

I want to keep the existing implicit conversion from py::bytes to py::str (because Wenzel suggested that can only change with a version change) but how?

Wouldn't this require a major version bump either way, because the first bullet point is a breaking change? I agree that it is the wrong behaviour, but I remember @jagerman talking about compatibility concerns regarding the first bullet point.

I might be repeating myself, but one more thing. Pybind11 is currently consistent when talking about string-like types. py::str, py::bytes, py::isinstance<T> do not change meaning at all when switching from python2 to python3. I feel that this consistency is important and saves us time when providing support for users.
If others don't think I'm right about this, that's fine. However, I reserve my right to say "told you so" eventually.

rwgk · 2020-07-31T16:16:26Z

Pybind11 is currently consistent when talking about string-like types. py::str, py::bytes, py::isinstance<T> do not change meaning at all when switching from python2 to python3.

That's some sort of consistent yes, but also highly misleading and outright useless. It's consistent only in some narrowly defined scope. If you look at the bigger picture: one major achievement of the very expensive Python 2 -> 3 transition is a clear delineation between str and bytes (Python 3 terminology). pybind11 as-is undoes that achievement and is inconsistent with Python semantics.

If anyone out there currently relies on isinstance<str> being true for both bytes & str (or str aka (!) bytes & unicode, respectively, in Python 2), it's probably an oversight, and fixing the bug on our end is more likely to uncover hidden bugs on their end than causing them an actual problem. If they really want isinstance<str> || isinstance<bytes> they can just add the second condition, making it obvious and explicit what they want, and it's even compatible with previous pybind11 versions. Compare the small and probably very rare inconvenience of having to add that condition to the ongoing confusion.

bstaletic · 2020-07-31T17:27:04Z

If they really want isinstance<str> || isinstance<bytes> they can just add the second condition, making it obvious and explicit what they want

I definitely agree with this. In fact, the above is what my own code is already doing. I was just pointing out that if we want to fix this, we will have to make a breaking change no matter what.

rwgk · 2020-07-31T18:44:03Z

I definitely agree with this. In fact, the above is what my own code is already doing. I was just pointing out that if we want to fix this, we will have to make a breaking change no matter what.

Cool, thanks!
We have #2348 now, thanks to @YannickJadoul , which IIUC allows us to cherry-pick changes that we consider safe for minor version number increments, while holding back other changes for major version number increments. I just have to learn / get used to the workflow now :-)

YannickJadoul · 2020-08-01T16:28:07Z

Hi @YannickJadoul I followed the instructions you gave me via chat: this PR is now based on the str-bytes-cleanup branch and set to merge into it. Thanks for the instructions, they worked for me without a problem.

BUT: Please do NOT review and definitely not merge yet. My next step will be to make the detail::PyUnicode_Check_Permissive to PyUnicode_Check change.

Great. Just shout when it's time to discuss consequences and dig up/judge old decisions ;-)

…bytes type to test_constructors(). (pybind#2340)

…rent behavior.

…g up tests

…e_str

…th that pybind11::str is guaranteed to be a PyUnicodeObject.

…version.

…load in pyobject_caster

…tes`). The corresponding behavior changes are captured by changes in the tests. A significant effort was made to keep the test diffs minimal but also comprehensive and easy to read. Note: Unlike PR pybind#2256 (dropped), this PR only changes exactly one behavior. The two other behavior changes discussed under PR pybind#2256 are avoided here (1. disabling implicit decoding from bytes to unicode; 2. list_caster behavior change). Based on this PR, those can be easily implemented if and when desired.

rwgk · 2020-08-11T01:25:23Z

This PR is obsoleted by #2380.

Dropping this PR because the convolution of 3 behavior changes lead to long discussions and no approvals :-)

PR #2380 changes only exactly one behavior. See PR description there.

…tes`). The corresponding behavior changes are captured by changes in the tests. A significant effort was made to keep the test diffs minimal but also comprehensive and easy to read. Note: Unlike PR pybind#2256 (dropped), this PR only changes exactly one behavior. The two other behavior changes discussed under PR pybind#2256 are avoided here (1. disabling implicit decoding from bytes to unicode; 2. list_caster behavior change). Based on this PR, those can be easily implemented if and when desired.

…tes`). The corresponding behavior changes are captured by changes in the tests. A significant effort was made to keep the test diffs minimal but also comprehensive and easy to read. Note: Unlike PR #2256 (dropped), this PR only changes exactly one behavior. The two other behavior changes discussed under PR #2256 are avoided here (1. disabling implicit decoding from bytes to unicode; 2. list_caster behavior change). Based on this PR, those can be easily implemented if and when desired.

…tes`). The corresponding behavior changes are captured by changes in the tests. A significant effort was made to keep the test diffs minimal but also comprehensive and easy to read. Note: Unlike PR pybind#2256 (dropped), this PR only changes exactly one behavior. The two other behavior changes discussed under PR pybind#2256 are avoided here (1. disabling implicit decoding from bytes to unicode; 2. list_caster behavior change). Based on this PR, those can be easily implemented if and when desired.

…tes`). The corresponding behavior changes are captured by changes in the tests. A significant effort was made to keep the test diffs minimal but also comprehensive and easy to read. Note: Unlike PR #2256 (dropped), this PR only changes exactly one behavior. The two other behavior changes discussed under PR #2256 are avoided here (1. disabling implicit decoding from bytes to unicode; 2. list_caster behavior change). Based on this PR, those can be easily implemented if and when desired.

rwgk force-pushed the isinstance_str branch from c577f60 to df84544 Compare June 19, 2020 22:19

rwgk force-pushed the isinstance_str branch from b66c8b4 to 468513d Compare July 21, 2020 00:22

rwgk mentioned this pull request Jul 22, 2020

test_builtin_casters.py test_string_view: Python 2 c++17, c++2a compa… #2314

Merged

rwgk force-pushed the isinstance_str branch 3 times, most recently from e20b54d to c78cc6a Compare July 22, 2020 20:53

wjakob reviewed Jul 23, 2020

View reviewed changes

bstaletic mentioned this pull request Jul 23, 2020

py::isinstance<py::str>(py_bytes_object) should not return true #1461

Closed

YannickJadoul self-requested a review July 24, 2020 22:23

YannickJadoul reviewed Jul 25, 2020

View reviewed changes

rwgk force-pushed the isinstance_str branch from c78cc6a to 7cddbb3 Compare July 28, 2020 22:39

This was referenced Jul 30, 2020

additional assert demonstrating that pybind::str can also by bytes in… #2343

Closed

Fixing pybind11::bytes() ambiguous overload issue and adding missing bytes type to test_constructors(). #2340

Merged

YannickJadoul mentioned this pull request Jul 31, 2020

Tracking PR: intermediate state of completed str/bytes cleaning up PRs #2348

Closed

4 tasks

rwgk force-pushed the isinstance_str branch from 7cddbb3 to b45c025 Compare August 1, 2020 01:06

YannickJadoul force-pushed the str-bytes-cleanup branch from 60cba1c to 3c8dbc2 Compare August 3, 2020 13:01

rwgk force-pushed the isinstance_str branch from 47f97a1 to c56d45e Compare August 3, 2020 19:41

Fixing pybind11::bytes() ambiguous overload issue and adding missing …

65130b7

…bytes type to test_constructors(). (pybind#2340)

rwgk force-pushed the str-bytes-cleanup branch from 3c8dbc2 to 65130b7 Compare August 4, 2020 19:14

Ralf W. Grosse-Kunstleve added 7 commits August 4, 2020 12:51

Adding test_isinstance_string_types, with asserts simply matching cur…

314b0d5

…rent behavior.

adding isinstance<str> specialization to match native behavior, fixin…

4c1e79a

…g up tests

reverting list_caster behavior to established: no more need for nativ…

f416fa6

…e_str

Replacing detail::PyUnicode_Check_Permissive with PyUnicode_Check. Wi…

423be92

…th that pybind11::str is guaranteed to be a PyUnicodeObject.

Making Python 2 pybind11::str::raw_string equivalent to the Python 3 …

e402c57

…version.

Re-introducing implicit bytes-to-unicode conversion with specialized …

f72a065

…load in pyobject_caster

adding test: pass_to_pybind11_unicode(malformed_utf8)

fe32344

rwgk force-pushed the isinstance_str branch from 72d95a6 to fe32344 Compare August 4, 2020 19:52

restoring original pybind11::str::raw_str implementation

d7add69

rwgk force-pushed the str-bytes-cleanup branch from 65130b7 to dcc41ef Compare August 7, 2020 01:45

rwgk mentioned this pull request Aug 11, 2020

Changing pybind11::str to only hold PyUnicodeObject (NOT also bytes). #2380

Merged

rwgk closed this Aug 11, 2020

rwgk deleted the isinstance_str branch August 11, 2020 01:25

rwgk mentioned this pull request Feb 10, 2023

FWD pybind11 google/pybind11clif#2256

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Adding test_isinstance_string_types, with asserts simply matching cur… #2256

Adding test_isinstance_string_types, with asserts simply matching cur… #2256

rwgk commented Jun 18, 2020

rwgk commented Jul 22, 2020

bstaletic commented Jul 22, 2020

rwgk commented Jul 22, 2020

bstaletic commented Jul 22, 2020

rwgk commented Jul 23, 2020

wjakob Jul 23, 2020

rwgk Jul 23, 2020

bstaletic Jul 23, 2020

rwgk Jul 23, 2020

bstaletic Jul 23, 2020

rwgk Jul 23, 2020

wjakob Jul 23, 2020

rwgk Jul 23, 2020

wjakob commented Jul 23, 2020

bstaletic commented Jul 23, 2020

rwgk commented Jul 23, 2020

YannickJadoul left a comment

YannickJadoul Jul 25, 2020

rwgk Jul 28, 2020

YannickJadoul Jul 28, 2020

YannickJadoul commented Jul 25, 2020

rwgk commented Jul 29, 2020

bstaletic commented Jul 31, 2020

rwgk commented Jul 31, 2020

bstaletic commented Jul 31, 2020

rwgk commented Jul 31, 2020

YannickJadoul commented Aug 1, 2020

rwgk commented Aug 11, 2020

Adding test_isinstance_string_types, with asserts simply matching cur… #2256

Adding test_isinstance_string_types, with asserts simply matching cur… #2256

Conversation

rwgk commented Jun 18, 2020

rwgk commented Jul 22, 2020

bstaletic commented Jul 22, 2020

rwgk commented Jul 22, 2020

bstaletic commented Jul 22, 2020

rwgk commented Jul 23, 2020

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

wjakob commented Jul 23, 2020

bstaletic commented Jul 23, 2020

rwgk commented Jul 23, 2020

YannickJadoul 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

YannickJadoul commented Jul 25, 2020

rwgk commented Jul 29, 2020

bstaletic commented Jul 31, 2020

rwgk commented Jul 31, 2020

bstaletic commented Jul 31, 2020

rwgk commented Jul 31, 2020

YannickJadoul commented Aug 1, 2020

rwgk commented Aug 11, 2020