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

Project status and plans #2

Closed
yang opened this issue Nov 3, 2015 · 2 comments
Closed

Project status and plans #2

yang opened this issue Nov 3, 2015 · 2 comments

Comments

@yang
Copy link

yang commented Nov 3, 2015

Hi, cool project! (As is any effort to bring static typing to Python, in my book.) What's the status of this project?

I tried throwing it at a couple of real code bases and it doesn't seem to be working. I can start debugging / posting issues, or if it's just not ready / meant for public consumption yet, I can save everyone's time and hold off. Or if there's some well-defined scope / set of limitations you can summarize, that would be immensely useful.

Also, is there some roadmap or timeline defined for this project? Esp. how that timeline compares to those of other on-going efforts such as mypy.

Lastly - is this a 20%/side project?

Thanks!

@matthiaskramm
Copy link
Contributor

It's a full-time project. We've been at it for a few years.

The version that's currently on github isn't very functional yet. I'll push a newer version soon.

We're also working on integrating http://github.com/python/typeshed, which will, I hope, fix a lot of the issues you have encountered, by providing a much more complete specification of all the Python builtins.

Apart from that, the biggest limitation I'm currently aware of is lack of if-splitting. So pytype will be confused by something like

x = []
if x:
  return x[0]

claiming that you can't retrieve an item out of an empty list. mypy works around this by making you declare a type for the elements in your empty list. In pytype, we're probably just going to do if-splitting.

@yang
Copy link
Author

yang commented Nov 7, 2015

Thanks!

@yang yang closed this as completed Nov 7, 2015
rchen152 added a commit that referenced this issue Dec 8, 2020
This is the original CL, plus these changes:
* Updated the third_party/py/numpy/__init__.pyi symlink.
* Updated the symlinks in devtools/python/blaze/pytype/.
* Started a [] train run: []

PiperOrigin-RevId: 345497968
rchen152 added a commit that referenced this issue Aug 14, 2023
* Reverts my previous attempt, which didn't handle overloads properly.
* Merges method signatures before resolving aliases.

PiperOrigin-RevId: 556082614
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

No branches or pull requests

2 participants