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.

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

Google sync #1036

Merged
merged 3 commits into from Oct 25, 2021
Merged

Google sync #1036

merged 3 commits into from Oct 25, 2021

Commits on Oct 25, 2021

  1. Address some new errors generated by dict() change. 

    * Fixes a crash caused by an overly specific assert.
* Puts the new dict() changes behind a feature flag,
  --build-dict-literals-from-kwargs. (Would love suggestions for a less wordy
  name...)

PiperOrigin-RevId: 404872878
    @rchen152
    rchen152 committed Oct 25, 2021
    Configuration menu
    Copy the full SHA
    e890e3d View commit details
    Browse the repository at this point in the history

  2. Update typing.NamedTuple to be considered a `typing.Tuple[{field_ty… 

    …pes...}]`.

Also applies a similar transform to `collection.namedtuple`. No type information of course, but the number of elements is now part of the type like with `typing.Tuple[Any, Any{, ...}]`

This fixes the last piece of `NamedTuple` being considered a type safe `Tuple` too.

As this is a breaking change, this is gaurded behind a `--strict_namedtuple_checks` flag. But this will become the default in the near future.

Before this, this code would erronously pass

```python
from typing import NamedTuple, Tuple

class X(NamedTuple):
  a: int
  b: str

x = X(42, "the answer")
dual_strings: Tuple[str, str] = x  # This should fail type checking, first element of X is an int
a_str: str = x[0]  # This should fail type checking too
```

Now it fails properly.

This also helps with some IDEs who are unaware of the extra context pytype keeps track of and thought `X` was a plain `tuple`, but not a `Tuple[int, str]`, so it wouldn't know the types after accessing them through tuple methods.
For example, with `X` and `x` as given above, for the construct: `a, b = x`, some IDE's would see the `tuple` "superclass" and assume `a` and `b` were `Any`.
Now it should treat it the same way as if it was `Tuple[int, str]` and preserve the typing. (Same with indexed element access)

Also, patches one hole in the type enforcement of the classic `collections.namedtuple`, where it would lose track of the size of the `Tuple` and would allow arbitrary sized destructuring assignment.

Before this, this code would erroneously pass

```python
import collections

X = collections.namedtuple("X", ["a", "b", "c"])

x = X("Friday", "Night", "Funkin")

a, b, c, d = x  # This should fail type checking, there are only 3 elements
a, b = x  # This should fail too
```

Now it fails properly

PiperOrigin-RevId: 404882510
    @rchen152
    Pytype Team authored and rchen152 committed Oct 25, 2021
    Configuration menu
    Copy the full SHA
    ed3a451 View commit details
    Browse the repository at this point in the history

  3. Prepare a PyPI release. 

    I also added a line to the CHANGELOG entry for last week's release for a change
that I forgot to mention.

PiperOrigin-RevId: 405460692
    @rchen152
    rchen152 committed Oct 25, 2021
    Configuration menu
    Copy the full SHA
    a98fb64 View commit details
    Browse the repository at this point in the history