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

Google sync #1036

Merged
merged 3 commits into from
Oct 25, 2021
Merged

Google sync #1036

merged 3 commits into from
Oct 25, 2021

Conversation

rchen152
Copy link
Contributor

No description provided.

rchen152 and others added 3 commits October 25, 2021 12:13
* 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
…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
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
@google-cla google-cla bot added the cla: yes label Oct 25, 2021
@rchen152 rchen152 merged commit 60e8346 into master Oct 25, 2021
@rchen152 rchen152 deleted the google_sync branch October 25, 2021 20:18
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.

1 participant