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

Allow NewType subclassing NewType. #3465

Merged
merged 1 commit into from May 28, 2017

Conversation

Projects
None yet
3 participants
@carljm
Contributor

carljm commented May 26, 2017

Use case: type hierarchy of IDs, all of which are integers at runtime, but we
want to type-check distinctions between e.g. "id of User" and "id of Media",
while still allowing some functions to take "any ID" (which is still a more
specific type than "any integer").

This seems to work as expected, it only requires removing an explicit guard
against it. Is there a reason to prohibit it? I didn't find any specific rationale
in the issue (#1284) or commit. @JukkaL raised it as a question in
#1284 (comment)
but it wasn't ever discussed further.

Allow NewType subclassing NewType.
Use case: type hierarchy of IDs, all of which are integers at runtime, but we
want to type-check distinctions between e.g. "id of User" and "id of Media",
while still allowing some functions to take "any ID" (which is still a more
specific type than "any integer").
@gvanrossum

This comment has been minimized.

Show comment
Hide comment
@gvanrossum

gvanrossum May 26, 2017

Member

Well, I don't think the spec of NewType in PEP 484 supports this. Also, does it work at runtime? (I suppose it would since NewType('x', int) just returns int.)

The use case sounds reasonable though.

@ilevkivskyi Thoughts?

Member

gvanrossum commented May 26, 2017

Well, I don't think the spec of NewType in PEP 484 supports this. Also, does it work at runtime? (I suppose it would since NewType('x', int) just returns int.)

The use case sounds reasonable though.

@ilevkivskyi Thoughts?

@carljm

This comment has been minimized.

Show comment
Hide comment
@carljm

carljm May 26, 2017

Contributor

Yeah, PEP 484 says that the second arg to NewType should be "a proper class, i.e., not a type construct like Union , etc." That's not really a clear declaration on the subject, but it could easily be read to prohibit this. OTOH NewType is sort of just an alias for a "proper class." And NewType already supports type aliases and generics.

Contributor

carljm commented May 26, 2017

Yeah, PEP 484 says that the second arg to NewType should be "a proper class, i.e., not a type construct like Union , etc." That's not really a clear declaration on the subject, but it could easily be read to prohibit this. OTOH NewType is sort of just an alias for a "proper class." And NewType already supports type aliases and generics.

@carljm

This comment has been minimized.

Show comment
Hide comment
@carljm

carljm May 26, 2017

Contributor

(And yes, it works fine at runtime.)

Contributor

carljm commented May 26, 2017

(And yes, it works fine at runtime.)

@ilevkivskyi

This comment has been minimized.

Show comment
Hide comment
@ilevkivskyi

ilevkivskyi May 28, 2017

Collaborator

I like the idea. This will require a small update to PEP 484. This indeed works at runtime (even for runtime introspection tools). For example:

Id = NewType('Id', int)
UserId = NewType('UserId', Id)
assert UserId.__supertype__.__name__ == 'Id'
assert UserId.__supertype__.__supertype__ is int
Collaborator

ilevkivskyi commented May 28, 2017

I like the idea. This will require a small update to PEP 484. This indeed works at runtime (even for runtime introspection tools). For example:

Id = NewType('Id', int)
UserId = NewType('UserId', Id)
assert UserId.__supertype__.__name__ == 'Id'
assert UserId.__supertype__.__supertype__ is int
@gvanrossum

This comment has been minimized.

Show comment
Hide comment
@gvanrossum

gvanrossum May 28, 2017

Member

OK, it does make sense, and go ahead with the PEP 484 update.

Member

gvanrossum commented May 28, 2017

OK, it does make sense, and go ahead with the PEP 484 update.

@gvanrossum gvanrossum merged commit 8c989bf into python:master May 28, 2017

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@ilevkivskyi

This comment has been minimized.

Show comment
Hide comment
@ilevkivskyi

ilevkivskyi May 30, 2017

Collaborator

OK, here is the PR python/peps#271 with the PEP 484 update.

Collaborator

ilevkivskyi commented May 30, 2017

OK, here is the PR python/peps#271 with the PEP 484 update.

gvanrossum added a commit to python/peps that referenced this pull request May 30, 2017

carljm added a commit to carljm/mypy that referenced this pull request May 30, 2017

Merge branch 'master' into module-alias
* master: (23 commits)
  Make return type of open() more precise (#3477)
  Add test cases that delete a file during incremental checking (#3461)
  Parse each format-string component separately (#3390)
  Don't warn about returning Any if it is a proper subtype of the return type (#3473)
  Add __setattr__ support (#3451)
  Remove bundled lib-typing (#3337)
  Move version of extensions to post-release (#3348)
  Fix None slice bounds with strict-optional (#3445)
  Allow NewType subclassing NewType. (#3465)
  Add console scripts (#3074)
  Fix 'variance' label.
  Change label for variance section to just 'variance' (#3429)
  Better error message for invalid package names passed to mypy (#3447)
  Fix last character cut in html-report if file does not end with newline (#3466)
  Print pytest output as it happens (#3463)
  Add mypy roadmap (#3460)
  Add flag to avoid interpreting arguments with a default of None as Optional (#3248)
  Add type checking plugin support for functions (#3299)
  Mismatch of inferred type and return type note (#3428)
  Sync typeshed (#3449)
  ...

topper-123 added a commit to topper-123/cpython that referenced this pull request Sep 22, 2017

DOCS: NewType can subclass NewType
It has become possible to create a ``NewType`` from an existing  ``NewType``, see python/mypy#3465 and python/peps#271.

This is a small update to the documentation as a concequence of the above change.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment