Support for no_type_check decorator by spkersten · Pull Request #645 · python/mypy

spkersten · 2015-04-19T18:14:20Z

Implements #557.

~~I've renamed the no_type_check decorator to no_type_checks.~~

Currently the typexport-basic tests fails because the no_type_check decorator I added to the typing.py stub shows up in the output of all tests.

gvanrossum · 2015-04-19T20:07:41Z

Why the rename? AFAIK the e PEP had the he singular.
On Apr 19, 2015 11:14 AM, "Sander Kersten" notifications@github.com wrote:

Implements #557 #557.

I've renamed the no_type_check decorator to no_type_checks.

Currently the typexport-basic tests fail for a weird reason.

You can view, comment on, or merge this pull request online at:

#645
Commit Summary

Renamed no_type_check decorator to no_type_checks.

Parse annotations of function decorated with 'no_type_checks' as
regular expression instead of type annotations.

Don't type check functions decorated with 'no_type_checks'

File Changes

M lib-typing/3.2/typing.py
https://github.com/JukkaL/mypy/pull/645/files#diff-0 (4)

M mypy/checker.py
https://github.com/JukkaL/mypy/pull/645/files#diff-1 (6)

M mypy/parse.py
https://github.com/JukkaL/mypy/pull/645/files#diff-2 (49)

M mypy/test/data/check-functions.test
https://github.com/JukkaL/mypy/pull/645/files#diff-3 (10)

M mypy/test/data/lib-stub/typing.py
https://github.com/JukkaL/mypy/pull/645/files#diff-4 (3)

Patch Links:

https://github.com/JukkaL/mypy/pull/645.patch

https://github.com/JukkaL/mypy/pull/645.diff

—
Reply to this email directly or view it on GitHub
#645.

spkersten · 2015-04-20T05:14:30Z

@gvanrossum Both [https://github.com/python/typing/issues/26](your comment) and #557 have the plural form. But I'll change it back to what the PEP say.

JukkaL · 2015-04-29T05:06:16Z

Thanks for the PR! I've been busy recently, but I had time for a quick a pass.

The implementation has a small limitation in that it detects the decorator based on the name. Something like this would not be detected:

from typing import no_type_check as my_annotations

@my_annotations
def foo(x: {1: 'x'}) -> 3: ...

I think this would also not work, which is may be a more realistic use case:

import typing

@typing.no_type_check
def foo(...) -> 2: ...

To implement these properly, we could accept arbitrary expressions in annotations during parsing, and only translate them to types during semantic analysis (but only if there is no no_type_check_ decorator). Not sure if this is important enough to implement now, but it would be more consistent with how names are bound elsewhere.

gvanrossum · 2015-04-29T05:21:19Z

I think the 'as' rename is uninteresting, but the @typing.no_type_check
form should be supported.

On Tuesday, April 28, 2015, Jukka Lehtosalo notifications@github.com
wrote:

Thanks for the PR! I've been busy recently, but I had time for a quick a
pass.

The implementation has a small limitation in that it detects the decorator
based on the name. Something like this would not be detected:

from typing import no_type_check as my_annotations
@my_annotationsdef foo(x: {1: 'x'}) -> 3: ...

I think this would also not work, which is may be a more realistic use
case:

import typing
@typing.no_type_checkdef foo(...) -> 2: ...

To implement these properly, we could accept arbitrary expressions in
annotations during parsing, and only translate them to types during
semantic analysis (but only if there is no no_type_check_ decorator). Not
sure if this is important enough to implement now, but it would be more
consistent with how names are bound elsewhere.

—
Reply to this email directly or view it on GitHub
#645 (comment).

--Guido van Rossum (on iPad)

spkersten · 2015-04-29T06:03:27Z

This is what I got stuck on; I wasn't happy with the string comparison on 'no_type_check'. Parsing types only after semantic analysis seemed the best solution, but is a lot more work.

If it's okay with you, I'll keep the string comparison for now (with both 'no_type_check' and 'typing.no_type_check'), as this feature is quite useful given the existing bugs/limitations in mypy. Separate of this, I'll try to figure out how to move the parsing of type to the semantic analysis phases.

On 29 apr. 2015, at 07:06, Jukka Lehtosalo notifications@github.com wrote:

Thanks for the PR! I've been busy recently, but I had time for a quick a pass.

The implementation has a small limitation in that it detects the decorator based on the name. Something like this would not be detected:

from typing import no_type_check as my_annotations

@my_annotations
def foo(x: {1: 'x'}) -> 3: ...
I think this would also not work, which is may be a more realistic use case:

import typing

@typing.no_type_check
def foo(...) -> 2: ...
To implement these properly, we could accept arbitrary expressions in annotations during parsing, and only translate them to types during semantic analysis (but only if there is no no_type_check_ decorator). Not sure if this is important enough to implement now, but it would be more consistent with how names are bound elsewhere.

—
Reply to this email directly or view it on GitHub.

…ar expression instead of type annotations.

…ing on a function.

spkersten · 2015-05-02T08:26:54Z

@JukkaL The no_type_check decorator I added to the typing.py stub shows up in the output of many typexport-basic tests. The comments intesttypegen.py suggest that it is not easy to suppress that from the output; and the things I tried were unsuccessful. Do you have any ideas how to fix this?

JukkaL · 2015-05-03T23:33:16Z

Here's a diff that fixes the test failures:

diff --git a/mypy/test/data/lib-stub/typing.py b/mypy/test/data/lib-stub/typing.py
index c96fa78..35d9977 100644
--- a/mypy/test/data/lib-stub/typing.py
+++ b/mypy/test/data/lib-stub/typing.py
@@ -16,6 +16,7 @@ Callable = object()
 builtinclass = object()
 _promote = object()
 NamedTuple = object()
+no_type_check = object()

 # Type aliases.
 List = object()
@@ -35,6 +36,3 @@ class Iterator(Iterable[T], Generic[T]):
 class Sequence(Generic[T]):
     @abstractmethod
     def __getitem__(self, n: Any) -> T: pass
-
-def no_type_check(func):
-    return func
\ No newline at end of file

The current convention is to initialize all 'special' names in typing.py stubs with object(). The initializer is actually arbitrary and it might be slightly better to use something like ... (literal ellipsis).

… decorator. Small fixes.

spkersten · 2015-05-05T08:44:38Z

Thanks for the explanation of how the stub works. I've applied your diff and fixed the handling of the @typing.no_type_check case.

JukkaL · 2015-05-12T04:53:19Z

Looks good now! Thanks again for the PR!

Support for no_type_check decorator

spkersten added 3 commits April 30, 2015 19:21

Parse annotations of function decorated with 'no_type_check' as regul…

db5308e

…ar expression instead of type annotations.

Don't type check functions decorated with 'no_type_check'

3530113

Added also typing.no_type_check as decorator that disables type check…

87ea9ca

…ing on a function.

spkersten force-pushed the no_type_checks branch from 6a09ee0 to 87ea9ca Compare May 2, 2015 08:21

spkersten changed the title ~~Support for no_type_checks decorator~~ Support for no_type_check decorator May 2, 2015

spkersten added 2 commits May 5, 2015 10:05

Changed typing.py stub to fix test_typegen tests.

e183f48

Added test case and fixed the handling of the '@typing.no_type_check'…

d84ccfe

… decorator. Small fixes.

JukkaL added a commit that referenced this pull request May 12, 2015

Merge pull request #645 from spkersten/no_type_checks

edd2b64

Support for no_type_check decorator

JukkaL merged commit edd2b64 into python:master May 12, 2015

JukkaL mentioned this pull request May 12, 2015

Document the no_type_check decorator #662

Closed

spkersten deleted the no_type_checks branch May 12, 2015 16:32

earwig mentioned this pull request Feb 3, 2021

typing.no_type_check is not understood microsoft/pyright#1448

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Support for no_type_check decorator#645

Support for no_type_check decorator#645
JukkaL merged 5 commits intopython:masterfrom
spkersten:no_type_checks

Uh oh!

Currently the typexport-basic tests fail for a weird reason.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

Uh oh!

Currently the typexport-basic tests fail for a weird reason.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants