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

Support for getting annotations from docstrings #103

Open
chadrik opened this issue Apr 18, 2020 · 6 comments
Open

Support for getting annotations from docstrings #103

chadrik opened this issue Apr 18, 2020 · 6 comments

Comments

@chadrik
Copy link
Contributor

chadrik commented Apr 18, 2020

Hi, me again. I created a tool, called doc484 much like pyannotate, for adding type comments based on docstrings. When I created my tool I was aware of pyannotate but assumed it just about generating annotations from types captured at runtime. Now that I realize it's really two separate tools, I think there are a lot of great features that could be added to pyannotate to make it a one-stop shop for generating/modifying type annotations.

doc484 is also implemented using lib2t3 and would be incredibly easy to add to pyannotate. It implies some additional features, like the ability to specify a fixer that should be considered a source of truth and should thus overwrite existing annotations if they are out of date (and dealing with the ramifications of that in a multi-fixer scenario).

Let me know what you think.

@gvanrossum
Copy link
Contributor

I wonder if the right thing to do isn't for you to just fork pyannotate? Since my retirement from Dropbox I simply don't have the time to review pyannotate contributions any more, and I believe the mypy team at Dropbox also doesn't have that much time to invest.

@chadrik
Copy link
Contributor Author

chadrik commented Apr 19, 2020 via email

@gvanrossum
Copy link
Contributor

Well, this repo is owned by Dropbox, and I am no longer a Dropbox employee, so l cannot merge anything. Hence my suggestion to fork.

@gvanrossum
Copy link
Contributor

Also, I've seen your contributions and I have no doubt about your skills or reliability. I suspect that Dropbox will be happy to see this project forked to get new energy and features into it!

@chadrik
Copy link
Contributor Author

chadrik commented Apr 20, 2020

I'd hate to fork the project if we can get some momentum going here, and also I don't really want to be on the hook for the runtime part of the project, which I have very little interest in. My plan is to submit a series of PRs here for the issues that I created, and if they get merged then great, otherwise, I'll create a fork of the project under a new name, likely without the runtime part.

Thanks for the guidance. And for.. y'know... python :)

@gvanrossum
Copy link
Contributor

From the resounding silence you can draw your own conclusions. I hope your fork takes flight!

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