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

Callable and Tuple should be subclassable. #299

Closed
ilevkivskyi opened this issue Oct 16, 2016 · 2 comments · Fixed by #308
Closed

Callable and Tuple should be subclassable. #299

ilevkivskyi opened this issue Oct 16, 2016 · 2 comments · Fixed by #308

Comments

@ilevkivskyi
Copy link
Member

One can subclass collections.abc.Mapping as well as typing.Mapping[str, int]. However, it is currently prohibited to subclass typing.Callable and typing.Tuple:

class C(collections.abc.Callable): ...  # works
class C(typing.Callable): ...           # fails

class C(typing.List[T]): ...            # works
class C(typing.Tuple[T, ...]): ...      # fails

I think that both Callable and Tuple should be subclassable (at least in the simple form shown above).

@gvanrossum If you agree, then you can assign this issue to me.

@gvanrossum
Copy link
Member

I'm not entirely against this, but IIRC this is intentional, since these
are not plain generic classes. Doing the right thing in the type checker
might be difficult. I think Callable should basically be treated as a duck
type (call) and if you want to subclass Tuple you should subclass tuple
instead. Probably. Maybe @JukkaL has more thoughts?

@JukkaL
Copy link
Contributor

JukkaL commented Oct 16, 2016

Early prototypes of typing actually supported subclassing Tuple[...]. I think that it's as reasonable as subclassing List[...], which is already supported. Subclassing tuple is not really a good alternative because then you can't specify the item types or the number of items, and instead it falls back to Tuple[Any, ...].

I think that Callable should use structural subtyping -- if __call__ is defined, it's a callable. Explicitly subclassing it seems kind of reasonable as well, for consistency with the collections.abc.Callable ABC, but it would be less useful than subclassing Tuple[...].

gvanrossum pushed a commit that referenced this issue Oct 29, 2016
Fixes #301 now ``List[Tuple[T, T]][int] == List[Tuple[int, int]]``
Fixes #298 now ``Table = Tuple[T, List[T]]`` can be used as generic type alias (as in PEP 484 example)
Fixes #299 now ``class MyTup(Tuple[int, ...]): ...`` is allowed
Fixes #156 (well, it does not substitute the annotations, but makes this task simple even in complex cases, see example in tests)

Also this PR fixes some minor things that I have found while working on this:
* ``List[Union]`` (with bare ``Union``, i.e. without arguments), ``List[Optional]``, ``List[Generic[T]]``, and ``List[ClassVar[int]]`` are not valid and are prohibited now.
* ``Generic`` did not evaluate forward references when asked, now it does.
* ``__qualname__`` was not copied on generic class subscription.
* Type was not erased on instantiation of subclasses of concrete containers (``List``, ``Set``, etc).
* There was an obscure bug in Python 2: sometimes ``_abc_registry`` was erased on instantiation.

The main idea of this PR is to fix the issues mentioned at the top by reusing the existing code. Namely, I pulled flattening and removing duplicates code from ``_Union`` and the tree calculation function ``_subs_tree`` from ``GenericMeta``. As well I moved ``Tuple`` and ``Callable`` _after_ ``GenericMeta`` and made them inherit the latter. So that now all types that could be generic store their info in common way using ``__origin__``, ``__parameters__``, ``__args__``.

I tried to polish this, to be sure that nothing was broken in the process of "refactoring" (also to improve speed). There is no recursion, the substitution tree is recalculated only when necessary. Also I added a lot of tests and many comments/docstrings (also for things added in my recent PRs).
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 a pull request may close this issue.

3 participants