prevent `tuple` subclasses from being interpreted as generic #3768

tybug · 2023-10-13T01:35:11Z

closes #3767.

Hypothesis is actually doing the "right" thing here. class Thing(namedtuple("Thing", [])) is a subclass of tuple which is both generic and a sequence. So providing concrete instantiations of Thing to eg st.from_type(Sequence[int]) type checks.

But, this seems to me like undesirable behavior: users treat namedtuples more like a struct or dataclass and not as either generic or a collection. ~~I've special-cased an exception against namedtuples here - but let me know if you prefer a different approach.~~ After discussion, this PR instead prevents any tuple subclasses from being interpreted as generic.

tybug · 2023-10-13T01:37:20Z

hypothesis-python/src/hypothesis/strategies/_internal/types.py

+    # namedtuples are, strictly speaking, generic. However, users treat them as
+    # dataclasses or structs, not as a generically typed collection, so we
+    # don't want to provide generic instantiations of these.
+    #
+    # Namedtuples aren't an actual type, so we'll check for internal attributes
+    # set by collections.namedtuple and hope nobody sets these on their own
+    # tuple subclass.
+    for t in sorted(mapping, key=type_sorting_key):
+        if (
+            isinstance(t, type)
+            and issubclass(t, tuple)
+            and hasattr(t, "_fields")
+            and hasattr(t, "_asdict")
+        ):
+            mapping.pop(t)
+


I'm not sure where this should appear in the function order-wise. There's a portion lower down where mapping is iterated over in the same way - maybe this check belongs there?

On line 395 above it drops things which are exactly type tuple, maybe we could expand that to drop any subtype of tuple too?

Seems reasonable, yeah. I think we'd want to discard os.Environ first, and then if there are non-tuple types discard all the tuple types. It's important that if you're resolving a namedtuple, or union of several, that works without discarding all or all-but-one!

I've updated as you described: if there is at least one other type, drop all tuple (sub)classes.

I admit I'm not sure what input to st.from_type would cause mapping to be filled with only tuple subclasses. This might be relevant if the cover tests yell at me for not providing an input which fails the new conditional branch 🙂

I think we need something along the lines of:

import abc class AbstractStruct(abc.ABC, tuple): @abstractmethod def foo(self): ... class ConcreteA(AbstractStruct): def foo(self): pass class ConcreteB(AbstractStruct): def foo(self): pass def test_handles odd tuple_subclasses(): s = st.from_type(AbstractStruct) assert_all_examples(s, lambda x: isinstance(x, AbstractStruct)) find_any(s, lambda x: isinstance(x, ConcreteA)) find_any(s, lambda x: isinstance(x, ConcreteB))

hmm, I don't think this works, because AbstractStruct doesn't pass this conditional:

hypothesis/hypothesis-python/src/hypothesis/strategies/_internal/core.py

Lines 1364 to 1369 in 9606972

if isinstance(thing, types.typing_root_type) or (

sys.version_info[:2] >= (3, 9)

and isinstance(get_origin(thing), type)

and get_args(thing)

):

return types.from_typing_type(thing)

I managed to come up with an alternative test involving a custom protocol whose only concrete instantiations are tuple subtypes - let me know what you think.

hypothesis-python/RELEASE.rst

Zac-HD · 2023-10-14T22:36:03Z

hypothesis-python/src/hypothesis/strategies/_internal/types.py

+    # namedtuples are, strictly speaking, generic. However, users treat them as
+    # dataclasses or structs, not as a generically typed collection, so we
+    # don't want to provide generic instantiations of these.
+    #
+    # Namedtuples aren't an actual type, so we'll check for internal attributes
+    # set by collections.namedtuple and hope nobody sets these on their own
+    # tuple subclass.
+    for t in sorted(mapping, key=type_sorting_key):
+        if (
+            isinstance(t, type)
+            and issubclass(t, tuple)
+            and hasattr(t, "_fields")
+            and hasattr(t, "_asdict")
+        ):
+            mapping.pop(t)
+


I think we need something along the lines of:

import abc class AbstractStruct(abc.ABC, tuple): @abstractmethod def foo(self): ... class ConcreteA(AbstractStruct): def foo(self): pass class ConcreteB(AbstractStruct): def foo(self): pass def test_handles odd tuple_subclasses(): s = st.from_type(AbstractStruct) assert_all_examples(s, lambda x: isinstance(x, AbstractStruct)) find_any(s, lambda x: isinstance(x, ConcreteA)) find_any(s, lambda x: isinstance(x, ConcreteB))

Zac-HD

Implementation looks great, thanks Liam!

See comment about an additional test case, and the release note formatting, then I think we're ready to merge 😁

Co-authored-by: Zac Hatfield-Dodds <zac.hatfield.dodds@gmail.com>

into namedtuple-generic

Zac-HD · 2023-10-15T01:47:16Z

hypothesis-python/tests/cover/test_lookup.py

+        pass
+
+
+def test_only_tuple_subclasses_in_typing_type():


I'd just skip this on Python 3.8, since it's using later typing features.

If we could also get a subclassing-based test working that'd make me more confident that future changes won't accidentally break something, but I'd be happy to merge without that too.

I slept on it, but I'm drawing a blank on a subclassing-based test (as opposed to using Protocol) where the only valid types are tuple types. I'd be happy to add it if someone else can come up with one, though.

Zac-HD

Rereading the full history here, yeah, you're right about the abstract class not actually working 😅

So I think it's ready to merge!

tybug · 2023-10-15T23:33:11Z

Thanks Zac! Happy to land my first contribution in Hypothesis, and looking forward to contributing more in the future!

prevent namedtuples from being interpreted as sequences

c237600

tybug commented Oct 13, 2023

View reviewed changes

tybug mentioned this pull request Oct 13, 2023

Incompatible Sequence types generated after register_type_strategy() #3767

Closed

tybug added 2 commits October 12, 2023 22:19

use typing alias to support pthon 3.8

65fec1d

reject all subclasses of tuple as generic

8a5bfca

tybug changed the title ~~prevent namedtuple from being interpreted as sequences~~ prevent tuple subclasses from being interpreted as generic Oct 14, 2023

tybug added 2 commits October 14, 2023 16:47

update release note

eec6a07

reformat

f523db1

Zac-HD reviewed Oct 14, 2023

View reviewed changes

tybug and others added 3 commits October 14, 2023 19:34

fix release notes wording

fc15290

Co-authored-by: Zac Hatfield-Dodds <zac.hatfield.dodds@gmail.com>

add test for a generic protocol whose only concrete subtypes are tuples

4a65e5a

Merge branch 'namedtuple-generic' of https://github.com/tybug/hypothesis

e398b28

into namedtuple-generic

Zac-HD reviewed Oct 15, 2023

View reviewed changes

h4l mentioned this pull request Oct 15, 2023

Allow strategy-generating functions to not provide strategies #3769

Merged

move tuple subclass test to py39

7c7375c

Zac-HD approved these changes Oct 15, 2023

View reviewed changes

Merge branch 'master' into namedtuple-generic

0d0ff88

Zac-HD enabled auto-merge October 15, 2023 22:26

Zac-HD merged commit a331d3e into HypothesisWorks:master Oct 15, 2023
47 checks passed

tybug deleted the namedtuple-generic branch October 15, 2023 23:32

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

prevent `tuple` subclasses from being interpreted as generic #3768

prevent `tuple` subclasses from being interpreted as generic #3768

tybug commented Oct 13, 2023 •

edited

tybug Oct 13, 2023 •

edited

h4l Oct 13, 2023

Zac-HD Oct 13, 2023 •

edited

tybug Oct 14, 2023

Zac-HD Oct 14, 2023

tybug Oct 14, 2023 •

edited

Zac-HD Oct 14, 2023

Zac-HD left a comment

Zac-HD Oct 15, 2023

tybug Oct 15, 2023

Zac-HD left a comment

tybug commented Oct 15, 2023

	if isinstance(thing, types.typing_root_type) or (
	sys.version_info[:2] >= (3, 9)
	and isinstance(get_origin(thing), type)
	and get_args(thing)
	):
	return types.from_typing_type(thing)

prevent tuple subclasses from being interpreted as generic #3768

prevent tuple subclasses from being interpreted as generic #3768

Conversation

tybug commented Oct 13, 2023 • edited

tybug Oct 13, 2023 • edited

Choose a reason for hiding this comment

h4l Oct 13, 2023

Choose a reason for hiding this comment

Zac-HD Oct 13, 2023 • edited

Choose a reason for hiding this comment

tybug Oct 14, 2023

Choose a reason for hiding this comment

Zac-HD Oct 14, 2023

Choose a reason for hiding this comment

tybug Oct 14, 2023 • edited

Choose a reason for hiding this comment

Zac-HD Oct 14, 2023

Choose a reason for hiding this comment

Zac-HD left a comment

Choose a reason for hiding this comment

Zac-HD Oct 15, 2023

Choose a reason for hiding this comment

tybug Oct 15, 2023

Choose a reason for hiding this comment

Zac-HD left a comment

Choose a reason for hiding this comment

tybug commented Oct 15, 2023

prevent `tuple` subclasses from being interpreted as generic #3768

prevent `tuple` subclasses from being interpreted as generic #3768

tybug commented Oct 13, 2023 •

edited

tybug Oct 13, 2023 •

edited

Zac-HD Oct 13, 2023 •

edited

tybug Oct 14, 2023 •

edited