GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — Revamped generic class behavior to conform to updated PEP 484 by gvanrossum · Pull Request #195 · python/typing

Conversation

@gvanrossum

@gvanrossum gvanrossum commented Mar 25, 2016

Copy link
Copy Markdown
Member

Fixes #115

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

1st reacted with thumbs up emoji
All reactions
  • 👍 1 reaction
Guido van Rossum added 6 commits March 24, 2016 16:58
Guido van Rossum
Revamp of generic classes. Dict[str, Tuple[S, T]] is now valid.
abefbe4
Still need to backport to python2.
Guido van Rossum
Backported revamp of generic classes to Python 2.
39324fa
Guido van Rossum
Make flake8 happy.
31b0e00
Guido van Rossum
Remove the last _has_type_var().
75518b0
Guido van Rossum
Backport fixing the __module__ attribute of a NamedTuple.
373338d
(Backport of 3819cbc,
CPython issue #25665.)
Guido van Rossum
Backport test_nested().
44a0488
@ilevkivskyi

ilevkivskyi commented Mar 25, 2016

Copy link
Copy Markdown
Member

It looks great! Still I have found something that I think could be confusing.

First, I would expect that Iterable[T][int] and Iterable[int] is the same type, but Iterable[T][int] == Iterable[int] gives me False.

Second (maybe related) issue is that now __repr__ shows the whole "history" of a type. For example, Iterable[Tuple[T,T]][int] is printed as __main__.Iterable<+T_co>[__main__.Tuple[~T, ~T]]<~T>[int]. This reads as first there was an Iterable parameterized by T_co, then it was indexed by Tuple[T, T] and we had something parameterized by T, and then it was indexed by int. The question is whether we need to expose all this information (that is rather internal) to the user? I think it would be more clear if __repr__ in this case will show something like Iterable[Tuple[int,int]].

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@gvanrossum

gvanrossum commented Mar 25, 2016

Copy link
Copy Markdown
Member Author

Ah, yes. I thought of making Iterable[T][int] == Iterable[int], but I ran out of steam on how to implement it. Then again, thinking about it I'm not sure that it's important to do this -- the runtime behavior of these things is of marginal interest and mypy doesn't let you write that anyway (the PEP is silent on whether this is allowed).

Ditto for repr(). The one important thing about repr() is that when you have

class C(Generic[T]): ...

then repr(C) shows C<~T> rather than C[~T] as it used to. I think the new form is better. And then C[Tuple[int, int]] will actually be printed as C<~T>[Tuple[int, int]]. The longer form (with alternating <...> and [...]) is only of theoretical importance.

Anyway, thanks for the encouragement. I hope others look over this important change too! I intend to land this in Python 3.5.2 (whenever it is released).

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@gvanrossum gvanrossum mentioned this pull request Mar 26, 2016
Decide meaning of alias with one generic and one concrete parameter #115
Closed
Guido van Rossum added 3 commits April 1, 2016 19:32
Guido van Rossum
Merge branch 'master' into new_generic (Fix #192).
5ed17e5
Guido van Rossum
Merge branch 'master' into new_generic (backport #192).
6a6119c
Guido van Rossum
Improve speed of Generic.__new__. Both PY2 and PY3. Fixes #196.
e0d1c5d
@ilevkivskyi

ilevkivskyi commented Apr 2, 2016

Copy link
Copy Markdown
Member

I am now thinking about one additional thing that might be not completely clear: covariance. If I initially have Iterable[T_co] covariant in its type parameter and write

class C(Iterable[Tuple[T,S]]):
    ...

then one could be not sure whether C is covariant in its variables or invariant. I think the natural answer is that covariance is determined only by the final list of type parameters, so that the class above is invariant in both variables. However, I didn't find anywhere in the PEP any explicit explanation of this point. Maybe it is obvious and it is only my problem of understanding, but if not then maybe one should add a short explanation to the PEP?

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@gvanrossum

gvanrossum commented Apr 3, 2016 via email

Copy link
Copy Markdown
Member Author
Good point. IMO nothing having to do with variance is obvious, so it would be good to spell it out. Right now I'm too tired to reason this through with a few examples, but my intuition says that your "natural" answer is probably correct. When I feel more rested I'll figure this out and add it to the PEP.
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@ilevkivskyi

ilevkivskyi commented Apr 3, 2016

Copy link
Copy Markdown
Member

I just noticed that this PR also fixes #129 . In general, I think this new "revamped" behavior is much better than the old one.

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@gvanrossum
gvanrossum merged commit 8c6aaf3 into master Apr 4, 2016
@gvanrossum gvanrossum mentioned this pull request Apr 4, 2016
Confusing __class__ for instance of non-generic class that subclasses generic class #129
Closed
@gvanrossum
gvanrossum deleted the new_generic branch April 26, 2016 15:33
@ilevkivskyi ilevkivskyi mentioned this pull request Oct 16, 2016
Allow type aliases such X = List[T] if T is a type variable python/mypy#606
Closed
ilevkivskyi added a commit to ilevkivskyi/typehinting that referenced this pull request Aug 19, 2017
@ilevkivskyi
Abandon attempts to support protocols in 3.5.0 and 3.5.1, see python#195
c8076ee
@ilevkivskyi ilevkivskyi mentioned this pull request Aug 21, 2017
Protocols in typing extensions #464
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Uh oh!

There was an error while loading. Please reload this page.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Uh oh!

There was an error while loading. Please reload this page.

2 participants

@gvanrossum @ilevkivskyi
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
You are visitor 01402503 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.