This is clearly something done in official capacity, during working hours, with the knowledge and support of his manager, who announced the CLI.
It says "This is not an officially supported Google product" because it's a DevRel sample/experiment, just like dozens of other Google repositories made by Google employees as part of their job.
Even some other tools in github.com/google have as much: https://github.com/google/python-fire / https://github.com/google/pytype/blob/main/docs/index.md / https://github.com/google/dopamine / https://github.com/google/go-tika
In Fired by Google for creating the Google workspace CLIgoogle
pytype
Python2015–2026
google / pytype · Archived
pytype
A static type analyzer for Python code
29Distinct people
42Mentions
0Explicit recommenders
5KGitHub stars
What to know before exploring
What it is
A static type analyzer for Python code
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- microsoft/pyright · linked in 6 of the same discussions
- meta/pyre-check · linked in 5 of the same discussions
- python/mypy · linked in 3 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 12:54:37 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year42 dated mentions
Observed mentions: 2015-11-25 19:50:34 UTC to 2026-06-24 07:29:24 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 8 | 2 | 6 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 2 | 0 | 2 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
An update on pytype
TL;DR: The last supported Python version for Pytype will be 3.12. We are
still very actively interested in the space of Python type checking, but
shifting our investments towards new ideas and different frameworks.
Pytype's development began in 2012 to meet Google developers' demand for
compile-time checking. Pytype started with using type inference and interface
files, and then switched to inline annotations (while retaining the inference
engine) after the acceptance of PEP 484. Later, pytype's team collaborated with
Guido and mypy to create typeshed, a central repository for type annotations.
While pytype has been effective, its bytecode-based design has presented
challenges in implementing new features (e.g. faster adoption of new typing
PEPs) due to bytecode’s inherent instability and propensity to change.
Consequently, we intend to focus our investments on exploring new typing
approaches that are better suited for Google’s Python user base and make
Python 3.12 the last supported version for pytype.
We encourage folks to investigate the mature and excellent alternative solutions
for Python typing going forward. We would like to note that the Python typing
ecosystem is very robust now, offering a wider array of mature solutions (see
FAQ).
The creation and development of pytype was a collaborative effort, and we would
like to thank all contributors to pytype, especially the four main contributors:
Rebecca Chen, Martin DeMello, Teddy Sudol, and initial lead Matthias Kramm.
We particularly recognize Rebecca Chen for her decade-long commitment to pytype
and her significant contributions to Python's type system as a long-standing
member of the typing council.
Read the full README on GitHubWhat Hacker News says
42 sourcesThere are plenty of such projects with similar disclaimers under Google's own /google/ organization. To give a few examples:
https://github.com/google/python-fire / https://github.com/google/pytype/blob/main/docs/index.md / https://github.com/google/dopamine / https://github.com/google/go-tika
Also plenty of official Google organizations that are not /google/ , but have official projects.
https://github.com/googleapis/googleapis/discussions/865 / https://github.com/google-research/big_vision / you can find plenty more
I wouldn't read too much into it, since it can mean virtually anything.
In Fired by Google for creating the Google workspace CLIin the related FAQ
https://github.com/google/pytype/issues/1925
they point explicitly to the future:
> What alternatives can I consider?
There are four Python static type checkers that can be considered: mypy and Pyright have been released to the community for a while and have well established user bases. Pyrefly, ty were announced recently at PyCon US 2025 and are in active development stage in the current time of August 2025 when this was written.
mypy - https://github.com/python/mypy
Pyright - https://github.com/microsoft/pyright
Pyrefly - https://github.com/facebook/pyrefly
ty - https://github.com/astral-sh/ty
In An Update on Pytypepytype is based in part upon byterun https://github.com/google/pytype/blob/main/docs/developers/i...
I learnt a lot about bytecode interpreters from working on it, and it helped me understand the cpython source code a lot more easily from having played with a python translation of it first.
In Writing that changed how I think about programming languagesThere is third, pytype (by google), which I found pretty good but it rarely gets mentioned. However, like the others it is slow, so I hope this one is fast and supports all the pytype features (especially being able to type-check un-annotated code).
https://github.com/google/pytype?tab=readme-ov-file#pytype--...
In "We're building a new static type checker for Python"pytype (https://github.com/google/pytype) is based on symbolic interpretation of python bytecode, but with the data stack storing types rather than values. it works very well and has been running in production within google forever.
the nice thing about writing a bytecode rather than an AST interpreter is that you can leverage a lot of the work the python compiler does, and work with the resulting simplified code.
In Python Meta Circular Interpreter (2019)There is also the rarely mentioned pytype from Google, written in Python. And pyright from Microsoft is written in Typescript, pyre at Facebook in OCaml. Last time I checked, these had better type inference algorithms (Hindley-Milner?) than mypy.
https://github.com/google/pytype
https://github.com/google/pytype
https://github.com/microsoft/pyright
In GIL Become Optional in Python 3.13my last job was working on [pytype](https://github.com/google/pytype), which uses abstract interpretation to do static type inference and checking for python. we used the cpython compiler to convert a program to bytecode, and then ran the bytecode through a VM where the abstract values were types. it worked extremely well, and could even typecheck completely unannotated code, though of course with less precision than when the user supplied some types.
extending that to runtime JIT compilation is an interesting idea; i'm not sure if any of the current JIT systems do that, but i don't see any reason it wouldn't be a useful technique, so they likely do.
In Abstract Interpretation in the Toy Optimizersome of them; others are internal tools used at google that the company is happy to let the devs open source, but which are not official google "products". my main project when I was at google was in that category: https://github.com/google/pytype - it was not an "official google product" in that google was not officially supporting it for external users, but it's an extensively used product within google and developing it was my full time job.
In Google Mesop: Build web apps in Pythonit's open source! check out https://github.com/google/pytype and https://github.com/google/pytype/blob/main/docs/developers/t... for more on the multi-file runner
In Google lays off its Python teamThere are static type checkers, though: https://github.com/google/pytype
So you can specify interfaces (protocols) and check them in your installation process.
In Should you use upper bound version constraints?So, I tried out pytype the other day, and it was a not a good experience. It doesn't support PEP 420 (implicit namespace packages), which means you have to litter __init__.py files everywhere, or it will create filename collisions. See https://github.com/google/pytype/issues/198 for more information. I've since started testing out pyre.
In Mypy 1.5 ReleasedWhat is the smart money doing for type checking in Python? I've used mypy which seems to work well but is incredibly slow (3-4s to update linting after I change code). I've tried pylance type checking in VS Code, which seems to work well + fast but is less clear and comprehensive than mypy. I've also seen projects like pytype [1] and pyre [2] used by Google/Meta, but people say those tools don't really make sense to use unless you're an engineer for those companies.
Am just curious if mypy is really the best option right now?
[1] https://github.com/google/pytype
[2] https://pyre-check.org/
In Writing Python like it's RustCheck out https://github.com/google/pytype
In The Python Paradox (2004)Showing the 15 most recent of 42 sources. Enable JavaScript to search and browse every indexed mention.