8000 Type[C] by gvanrossum · Pull Request #1569 · python/mypy · GitHub
[go: up one dir, main page]
Skip to content

Type[C] #1569

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 23 commits into from
Jun 8, 2016
Merged

Type[C] #1569

merged 23 commits into from
Jun 8, 2016

Conversation

gvanrossum
Copy link
Member

TBD

rwbarton
rwbarton reviewed May 24, 2016
View reviewed changes
mypy/applytype.py
# Translate constructor fn back to class.
if isinstance(type, CallableType) and type.is_type_obj():
types[i] = type = type.ret_type

Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think this is right, though somehow it never made a difference in my tests. The value C (the class) is not the same sort of thing as an instance of the class C.

@rwbarton
Copy link
Contributor

Do you plan to add support for invoking a class method on a value of type Type[C]?

@gvanrossum
Copy link
Member Author

Of course; I hope that already works.

--Guido (mobile)
On May 25, 2016 10:03 AM, "Reid Barton" notifications@github.com wrote:

Do you plan to add support for invoking a class method on a value of type
Type[C]?

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#1569 (comment)

@gvanrossum
Copy link
Member Author
gvanrossum commented May 25, 2016 via email

@gvanrossum
Copy link
Member Author
gvanrossum commented May 25, 2016 via email

Guido van Rossum added 10 commits June 6, 2016 15:28
Tentative tests for Type[C].
b7ddf36
Pave the way for implementing Type[C].
eb61f1d
WIP: Introducing TypeType: Type[x] becomes TypeType(x).
7b52ac6
WIP: Fix/new tests; implement more subtype checks.
1fd14f0
WIP: Towards supporting Type[T].
371e425 
The TypeC tests no pass except for one ProUser* that should be
ProUser; but something's seriously wrong because many other tests now
fail.
Fix things so all tests pass!
96696ff
Some cleanup and fixup (not done).
aa37595 
- Add tests for Type[Any] and plain Type, and fix a bug that found.
- Respond to easy review feedback (adding comments/docstrings mostly).
Improve equivalence between type and Type.
d4745b0
Add support for method lookup from Type[].
cf4a0b7 
We only support two special cases (hopefully the most common ones):

- Type[<concrete_class>]
- Type[<type_variable_with_concrete_class_upper_bound>]
Print a proper error for unsupported Type[] args.
81ee239 
(This happens when type checking a call, not during semantic analysis.)
@gvanrossum
Copy link
Member Author

Another look? I've addressed all XXX comments, and added more tests. Would like to get this in 0.4.2.

@gvanrossum
Copy link
Member Author

Ignore AppVeyor. I don't know why it keeps doing this even though I removed appveyor.yml.

JukkaL
JukkaL reviewed Jun 7, 2016
View reviewed changes
mypy/test/data/check-classes.test
class User: pass
class ProUser(User): pass
def new_user(user_class: Type[User]) -> User:
return user_class()
Copy link
Collaborator

Choose a reason for hiding this comment

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

Test calling with invalid arguments to __init__. Also test a class with non-default __init__ and call constructor with both valid and invalid arguments.

@gvanrossum
Copy link
Member Author

Please ignore the AppVeyor build, as usual.

@gvanrossum gvanrossum mentioned this pull request Jun 7, 2016
Closed
@gvanrossum
Copy link
Member Author

Addressed all remaining comments.

JukkaL
JukkaL reviewed Jun 7, 2016
View reviewed changes
mypy/join.py
elif isinstance(self.s, Instance) and self.s.type.fullname() == 'builtins.type':
return self.s
else:
return AnyType()
Copy link
Collaborator

Choose a reason for hiding this comment

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

Don't return AnyType here -- instead, use self.default(self.s), which usually returns object.

@JukkaL
Copy link
Collaborator
JukkaL commented Jun 7, 2016

Looks pretty good now! Here are a few additional things to test:

  • More tests for Type[Any]. I think we agreed that it shouldn't be possible to access arbitrary attributes, but this should be callable with arbitrary arguments. It's worth testing these.
  • What if C is a named tuple in Type[C]? I assume that it hits the regular tuple code path but it's worth adding a test case, as named tuples sometimes behave badly.
  • I think there isn't a test for calling Type[C] if C has an overloaded __init__. Worth testing this, as overloaded methods occasionally cause trouble.
  • Test a case where we use join during type inference, such as expression [ta, tc] where type of ta is Type[A] and type of tb is Type[B], and B is a subclass of A.

These are optional but if you don't implement these consider creating issues:

  • Should Type[C] be a subtype of Callable[..] in case the signature is compatible?
  • If yes, we should also infer constraints for a Callable template and TypeType actual.
  • If yes, join and meet will likely also be affected.

@gvanrossum
Copy link
Member Author

Pushed solutions for the first 4 bullets.

@gvanrossum
Copy link
Member Author
gvanrossum commented Jun 7, 2016 •
edited
Loading

Looks like Type[C] is indeed a subtype of Callable[[], C]:

class C: pass
T = Type[C]
def f(a: Callable[[], C]) -> None: pass
f(C)
f(T)

has no errors. I can write a more elaborate test after lunch.

UPDATE: But I'm not sure what the last two bullets imply then.
UPDATE2: Filed #1670 for that, left this PR unchanged.

@gvanrossum gvanrossum mentioned this pull request Jun 7, 2016
Closed
@JukkaL JukkaL merged commit 8555adb into master Jun 8, 2016
@gvanrossum gvanrossum deleted the typec branch June 8, 2016 17:10
@elazarg elazarg mentioned this pull request Jul 3, 2018
Merged
ilevkivskyi pushed a commit that referenced this pull request Aug 2, 2018
@elazarg @ilevkivskyi
Allow calling Type[T] where T has generic bound (#5309)
573be3e 
Fix #3631 : looks like it was an explicit decision, made before we had self types.

The code modified in this PR was introduced at #1569. There are no tests for the current behavior, and it seems like we actually want to allow it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@gvanrossum @rwbarton @JukkaL
0