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

bpo-46571: improve typing.no_type_check to skip foreign objects #31042

Merged
merged 3 commits into from
Feb 19, 2022

Conversation

sobolevn
Copy link
Member

@sobolevn sobolevn commented Feb 1, 2022

There are several changes:

  1. We now don't explicitly check for any base / sub types, because new name check covers it
  2. I've also checked that no_type_check do not modify foreign functions. It was the same as with types
  3. I've also covered except TypeError in no_type_check with a simple test case, it was not covered at all
  4. I also felt like adding lambda test is a good idea: because lambda is a bit of both in class bodies: a function and an assignment

Are there any other cases we want to cover?

https://bugs.python.org/issue46571

@AlexWaygood
Copy link
Member

AlexWaygood commented Feb 1, 2022

Here's a slightly evil corner case that this patch doesn't account for:

If I have a module typing_test.py, like so:

# typing_test.py
class A:
    class AA:
        foo: int

Then, observe the following behaviour (with your patch applied):

>>> from typing import get_type_hints, no_type_check
>>> import typing_test
>>> get_type_hints(typing_test.A.AA)
{'foo': <class 'int'>}
>>> @no_type_check
... class A:
...     AA = typing_test.A.AA
... 
...     
>>> get_type_hints(typing_test.A.AA)
{}

We might be able to get around this by looking at the __module__ attribute.

Lib/test/test_typing.py Show resolved Hide resolved
Lib/typing.py Outdated Show resolved Hide resolved
@sobolevn
Copy link
Member Author

sobolevn commented Feb 2, 2022

@AlexWaygood good one! Very evil!

I've addressed this.

@JelleZijlstra I agree that we should also fix classmethod / staticmethod problem. Because we declare to support all methods, not just instance methods.

The problem is that types.MethodType does not support attribute assignment:

>>> class Some:
...     @staticmethod
...     def st(x: int) -> int: ...
...     @classmethod
...     def cl(cls, y: int) -> int: ...

>>> Some.st.__no_type_check__ = True

>>> Some.cl.__no_type_check__ = True
AttributeError: 'method' object has no attribute '__no_type_check__'

Ideas?

Moreover, do we need some special @property support?

@AlexWaygood
Copy link
Member

@AlexWaygood good one! Very evil!

I've addressed this.

Doesn't look like you've pushed anything -- did you mean to? :)

@sobolevn
Copy link
Member Author

sobolevn commented Feb 2, 2022

Doesn't look like you've pushed anything -- did you mean to? :)

Not yet, I am still fighting classmethod 🙂

@sobolevn
Copy link
Member Author

sobolevn commented Feb 2, 2022

Probably

if isinstance(obj, types.MethodType):
                obj.__func__.__no_type_check__ = True

is the way to go 🤔

Will write some more tests to be sure.

Copy link
Member

@JelleZijlstra JelleZijlstra left a comment

Choose a reason for hiding this comment

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

Looks good.

Do you think this should be backported? I'm leaning no as it's a behavior change and nobody directly complained about the old behavior (looks like you found it while reviewing typing test coverage).

Copy link
Member

@gvanrossum gvanrossum left a comment

Choose a reason for hiding this comment

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

Agreed, a backport doesn't seem asked for.

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 this pull request may close these issues.

6 participants