Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simplify Collection. #10450

Merged
merged 2 commits into from Jul 26, 2020
Merged

Simplify Collection. #10450

merged 2 commits into from Jul 26, 2020

Conversation

jsirois
Copy link
Member

@jsirois jsirois commented Jul 25, 2020

Collection and its subclasses are now just new-types for tuple removing
the previously awkward dependencies field exposed for the engine. The
engine is updated to handle these Collections as Iterable Python
objects when attempting to collect their contained values.

Collection and its subclasses are now just new-types for tuple removing
the previously awkward `dependencies` field exposed for the engine. The
engine is updated to handle these Collections as Iterable Python
objects when attempting to collect their contained values.
Copy link
Contributor

@Eric-Arellano Eric-Arellano left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great! Thank you.

Test failures revealed isinstance for types derived from tuple behaves
unexpectedly under Python3.6. Although this can be worked around by
saving off the mro in __init_subclass__ and using that to perform a
custom isinstance check, more investigation indicated two aspects of
the status quo were undesirable:

1. By returning NotImplemented we left equality up to foreign types
to decide.
2. The intended use of Collection subtypes is for the engine, which
treats all types as distinct; yet we would compare subtypes as equal.

As such implement exact type match based equality and document this.
@jsirois
Copy link
Member Author

jsirois commented Jul 26, 2020

PTAL.

So ... isinstance(..., subclass-of-tuple) behaves not like you'd expect in Python3.6. Works fine in 3.7 and 3.8. I spent a good chunk of time debugging this and then coming up with a performant workaround, but then realized we should have just been checking for identical types anyhow al along. So I switched to that and that semantic change probably deserves another look / more brains considering.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 0.0% when pulling 2e04a7b on jsirois:Collection/simplify into 0a61cf8 on pantsbuild:master.

@jsirois jsirois merged commit 725fdaf into pantsbuild:master Jul 26, 2020
@jsirois jsirois deleted the Collection/simplify branch July 26, 2020 19:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants