Added support for Concatenate with Ellipsis

[Daraan]

Fixes #110.

This PR adds support for Ellipsis in Concatenate for the Python 3.8-3.10 backports.

Does not fix:

• Concatenate implementation generates runtime exception if parameterized by ... #48 : Using Ellipsis as argument for Callable with a generic..
  • <= 3.9: because of typing.Callable limitations
  • For 3.10 could go back to typing_extentions._ConcatenateGenericAlias but also tricky.

Changes:

• Changed _concatenate_getitem to reflect the Python3.11 typing module that allows the Ellipsis parameter.
• For Python 3.10 uses typing._ConcatenateGenericAlias and _concatenate_getitem
• For <=Python 3.9 the typing_extensions._ConcatenateGenericAlias and _concatenate_getitem like before
• For <3.9.2 uses a Dummy class that is temporarily swapped with an Ellipsis input
• Added tests

[cpython-cla-bot]

All commit authors signed the Contributor License Agreement.

[JelleZijlstra]

Thanks for these fixes!

Please avoid force pushing for future changes; it makes it harder to track the history of the code. Instead, just push new commits to your branch, and we'll squash them when we merge the PR.

[Daraan]

I've made a rework (moved the parts to _create_concatenate_alias) that is now simpler and also works for Python 3.8 and fully solves #110 on the current version range.

[Daraan]

Should the __args__ here be replaced by get_args?

[AlexWaygood]

fine to keep it as it is, realistically this attribute is never going away :)

[AlexWaygood]

I wonder if it's really worth adding this test? It seems like in later Python versions we decided that it was better to not raise exceptions in these cases, so that seems like the "desirable" behaviour, since we aim to reflect the behaviour in the latest version of the typing module as much as possible. That means that therefore the behaviour of raising exceptions on these in earlier Python versions is sort-of undesirable behaviour. I wouldn't see it as a big priority for us to fix it, but I'm also not sure it's necessary to have these assertions, if they're arguably asserting undesirable behaviour?

[Daraan]

Thank you for the reasoning and I do agree with you. The reasons why _type_check was made more lax was to prevent bugs and have less restrictions to implement new features.

The only reason I see to keep at least the original test would be to test for a regression like forgetting to call _type_check at all.

I would roll back the new test, it does not test something that is desirable to not pass. However, the reason to keep the other one around is not that strong. Would you prefer to keep it? In that case I'll add some comment to it.

[Daraan]

I've changed the test to assure the _type_check but with the currently undesired behavior.

[AlexWaygood]

Looks like you might have closed this accidentally. Probably this is something to do with the fact that it was a PR from your fork's main branch. I think it's unfortunately impossible to repair PRs when they get to this state — do you want to recreate the PR using a different branch on your fork? :-)

[Daraan]

Thanks for your kind reply. Yep I've just butchered this 🙈, I am sorry. It's as you assume related to the fork from main ...

[AlexWaygood]

We've all been there, pretty sure I've done it at least once :-)