Skip to content

[WIP] add stubs for typing #231

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

Closed
wants to merge 12 commits into from
Closed

[WIP] add stubs for typing #231

wants to merge 12 commits into from

Conversation

blueyed
Copy link
Contributor

@blueyed blueyed commented Jan 13, 2020

This is meant to be used for pytest, which mainly uses py.path.local, and is very much work in progress.

/cc @bluetech

@blueyed
Copy link
Contributor Author

blueyed commented Jan 17, 2020

btw: https://github.com/davidfritzsche/pytest-mypy-testing/ might be interesting for testing the stubs.

@bluetech
Copy link
Member

Awesome! Will really help with pytest typing.

I have some general comments below, will follow up with concrete comments.

First, I assume that given py is in maintenance mode, the idea is only to add typing for external use and not for internal/development use. And also that we'll probably never want to integrate the types into the code itself, only pyi files.

Given that, I think that the stubs should only really expose the public API, and not include internal/private details. And also, only importable items (functions, classes, etc.) should be included. Or if we want to expose private items, we should prefix them with _ so it's clear they are only "helpers" for the stubs (this is what typeshed does).

py does some weird things with imports but the __init__.py at least makes it very easy to see what is the public API of the package.

@blueyed
Copy link
Contributor Author

blueyed commented Jan 17, 2020

@bluetech
Agree!
Most of the internal things is generated via stubgen, I am adjusting it as I find issues - have not really checked if I am missing some local changes.
It's rather messy still, but when installed helps mypy already.

@@ -0,0 +1,8 @@
from py._error import ErrorMaker
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ErrorMaker is not exposed so I'd add it with underscore.

@@ -0,0 +1,8 @@
from py._error import ErrorMaker

from . import path
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems better to me not to import here, but instead handle as a sub-package in the stubs. That is, add py/path/__init__.pyi. (We might want to separate the stubs to some separate source tree, if that's even possible, so it doesn't affect the real package).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We might want to separate the stubs to some separate source tree, if that's even possible, so it doesn't affect the real package

py/path is empty without the stubs.
Do you mean to keep py/path/*.pyi there then, or do you mean to use something like py/_typed/…?

The idea of using the main __init__.pyi was to see what's really exposed/used - but I guess since it is used from/via py/path that is something mypy looks at also already.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I saw later that you already added py/path directory, so you can just delete this line already, as it's redundant with the subpackage.

My comment about "separate source tree" was that adding actual py/path directory might have some affect on runtime module resolution? With namespace packages and such? I.e. currently import py.path.foo goes thru the py import hackery to the private py._path package, but if you we add actual py/path directory does it break anything?

If not then great :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure, but I assume it is fine, since there is only .pyi, no .py.

from py._error import ErrorMaker

from . import path
from ._vendored_packages import iniconfig
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same for iniconfig and io re. subpackages.

@@ -0,0 +1,72 @@
import ctypes
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The only types from this file that are exposed in py.io are the following, so I'd just leave those and delete everything else!

'TerminalWriter'      : '._io.terminalwriter:TerminalWriter',    
'ansi_print'          : '._io.terminalwriter:ansi_print',
'get_terminal_width'  : '._io.terminalwriter:get_terminal_width',

@@ -0,0 +1,94 @@
import sys
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For py.path, we should only expose class local. LocalPath is not importable directly, only as the py.path.local. And the SVN stuff I guess is dead and better to leave out.

Should remove everything else from this file and py/path/common.pyi or expose underscored if referenced indirectly by an exposed item.

@bluetech
Copy link
Member

BTW, I just checked the pytest code and from the best I can find, these are the imports from py that pytest uses:

py.error.Error

py.iniconfig.IniConfig
py.iniconfig.ParseError

py.io.dupfile
py.io.get_terminal_width
py.io.TerminalWriter

py.path.local

py.xml.escape
py.xml.Namespace
py.xml.raw

Might help direct the focus.

@bluetech
Copy link
Member

Most of the internal things is generated via stubgen, I am adjusting it as I find issues - have not really checked if I am missing some local changes.

stubgen is great for this, but I think we should take its output, trim it down and restructure it, as I suggested above, and later also fill up the Anys. WDYT?

(I can help with the effort if you'd like)

@blueyed
Copy link
Contributor Author

blueyed commented Jan 17, 2020

stubgen is great for this, but I think we should take its output, trim it down and restructure it, as I suggested above, and later also fill up the Anys. WDYT?

Sure, of course.

Your help would be appreciated of course.
Feel free to go crazy on the branch - hopefully you can push here?

@bluetech
Copy link
Member

Your help would be appreciated of course.
Feel free to go crazy on the branch - hopefully you can push here?

Great, I can do it now. I'll just send a PR with my suggestions against your repo so you can decide what to do.

@blueyed blueyed mentioned this pull request Jan 19, 2020
@blueyed
Copy link
Contributor Author

blueyed commented Jan 19, 2020

Closing in favor of #232.

@blueyed blueyed closed this Jan 19, 2020
@blueyed blueyed deleted the pyi branch January 19, 2020 11:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants