Skip to content

Fine-grained: Inconsistent behavior for nested NewType #4615

Open

Description

@JukkaL

The output of the second increment of this fine-grained incremental mode test case doesn't generate an error, even though nothing relevant has changed:

[case testRefreshNestedNewType]
import a
[file a.py]
from typing import Union, NewType
import b

def f(self) -> None:
    X = NewType('X', A)

A = str
[file b.py]
y = 0
[file b.py.2]
y = ''
[out]

Here's the output:

a.py:5: error: Argument 2 to NewType(...) must be subclassable (got A?)
==

The expected output would be identical for both runs.

The output from the first and second runs also does not match for this slightly different test case:

[case testRefreshNestedNewType]
import a
[file a.py]
from typing import Union, NewType
import b

def f(self) -> None:
    X = NewType('X', A)

A = Union[int, str]

[file b.py]
y = 0
[file b.py.2]
y = ''
[out]

Here's the output (again expected to be identical):

a.py:5: error: Argument 2 to NewType(...) must be subclassable (got A?)
==
a.py:5: error: Argument 2 to NewType(...) must be subclassable (got "Union[int, str]")

It looks like forward references within NewType declarations behave inconsistently.

Activity

  1. ilevkivskyi commented on Feb 21, 2018

    @ilevkivskyi
    Member

    I think that at least the second one (with union) should be fixed by my alias PR #4525. My guess is that things that should be stripped are not stripped (like .analyzed).

  2. ilevkivskyi commented on Feb 21, 2018

    @ilevkivskyi
    Member

    Also there is in fact no big difference between two examples from point of view of forward refs vs NewType, in the first case the analyzed forward ref is str which is a valid base class, therefore no error is shown.

  3. self-assigned this
    on Feb 23, 2018
  4. ilevkivskyi commented on Mar 16, 2018

    @ilevkivskyi
    Member

    It looks like strip_target is not called on a.py, while it should. Therefore, the type aliases are not stripped, and appear in analyzed form on the second run. I am not yet sure how to fix this.

  5. ilevkivskyi commented on Mar 20, 2018

    @ilevkivskyi
    Member

    After a discussion with @JukkaL it looks like the right solution for now would be to support forward references in NewTypes. We anyway allow them in many places where they should be prohibited, so this is consistent.

  6. removed their assignment
    on Dec 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions