[LSP] 试用Python开发新包 lsp-pyright

lpfrylzx · 2021 年5 月 3 日 17:23

把其他工具中生成的pyi文件放到我们的site-packages目录里面实现自动补全，比如：把.vscode/extensions/ms-python.vscode-pylance-xxx/dist/bundled/native-stubs/cv2/cv2.pyi放到site-packages/cv2

seagle0128 · 2021 年5 月 4 日 14:07

都不看上面贴出的文档吗？一个命令行就搞定事情。

jesse · 2021 年5 月 4 日 16:41

看不出哪个帖子是文档

Voleking · 2021 年5 月 5 日 04:06

github.com

microsoft/pyright/blob/main/docs/type-stubs.md#generating-type-stubs-from-command-line

# Type Stub Files

Type stubs are “.pyi” files that specify the public interface for a library. They use a variant of the Python syntax that allows for “...” to be used in place of any implementation details. Type stubs define the public contract for the library.

## Importance of Type Stub Files

Regardless of the search path, Pyright always attempts to resolve an import with a type stub (“.pyi”) file before falling back to a python source (“.py”) file. If a type stub cannot be located for an external import, Pyright will try to use inline type information if the module is part of a package that contains a “py.typed” file (defined in [PEP 561](https://www.python.org/dev/peps/pep-0561/)). If the module is part of a package that doesn’t contain a “py.typed” file, Pyright will treat all of the symbols imported from these modules will be of type “Unknown”, and wildcard imports (of the form `from foo import *`) will not populate the module’s namespace with specific symbol names.

Why does Pyright not attempt (by default) to determine types from imported python sources? There are several reasons.

1. Imported libraries can be quite large, so analyzing them can require significant time and computation.
2. Some libraries are thin shims on top of native (C++) libraries. Little or no type information would be inferable in these cases.
3. Some libraries override Python’s default loader logic. Static analysis is not possible in these cases.
4. Type information inferred from source files is often of low value because many types cannot be inferred correctly. Even if concrete types can be inferred, generic type definitions cannot.
5. Type analysis would expose all symbols from an imported module, even those that are not meant to be exposed by the author. Unlike many other languages, Python offers no way of differentiating between a symbol that is meant to be exported and one that isn’t.

If you’re serious about static type checking for your Python source base, it’s highly recommended that you consume “py.typed” packages or use type stub files for all external imports. If you are unable to find a type stub for a particular library, the recommended approach is to create a custom type stub file that defines the portion of that module’s interface used by your code. More library maintainers have started to provide inlined types or type stub files.

## Generating Type Stubs
If you use only a few classes, methods or functions within a library, writing a type stub file by hand is feasible. For large libraries, this can become tedious and error-prone. Pyright can generate “draft” versions of type stub files for you.

This file has been truncated. show original

seagle0128 · 2021 年5 月 5 日 04:48

github.com

microsoft/pyright/blob/main/docs/type-stubs.md

# Type Stub Files

Type stubs are “.pyi” files that specify the public interface for a library. They use a variant of the Python syntax that allows for “...” to be used in place of any implementation details. Type stubs define the public contract for the library.

## Importance of Type Stub Files

Regardless of the search path, Pyright always attempts to resolve an import with a type stub (“.pyi”) file before falling back to a python source (“.py”) file. If a type stub cannot be located for an external import, Pyright will try to use inline type information if the module is part of a package that contains a “py.typed” file (defined in [PEP 561](https://www.python.org/dev/peps/pep-0561/)). If the module is part of a package that doesn’t contain a “py.typed” file, Pyright will treat all of the symbols imported from these modules will be of type “Unknown”, and wildcard imports (of the form `from foo import *`) will not populate the module’s namespace with specific symbol names.

Why does Pyright not attempt (by default) to determine types from imported python sources? There are several reasons.

1. Imported libraries can be quite large, so analyzing them can require significant time and computation.
2. Some libraries are thin shims on top of native (C++) libraries. Little or no type information would be inferable in these cases.
3. Some libraries override Python’s default loader logic. Static analysis is not possible in these cases.
4. Type information inferred from source files is often of low value because many types cannot be inferred correctly. Even if concrete types can be inferred, generic type definitions cannot.
5. Type analysis would expose all symbols from an imported module, even those that are not meant to be exposed by the author. Unlike many other languages, Python offers no way of differentiating between a symbol that is meant to be exported and one that isn’t.

If you’re serious about static type checking for your Python source base, it’s highly recommended that you consume “py.typed” packages or use type stub files for all external imports. If you are unable to find a type stub for a particular library, the recommended approach is to create a custom type stub file that defines the portion of that module’s interface used by your code. More library maintainers have started to provide inlined types or type stub files.

## Generating Type Stubs
If you use only a few classes, methods or functions within a library, writing a type stub file by hand is feasible. For large libraries, this can become tedious and error-prone. Pyright can generate “draft” versions of type stub files for you.

This file has been truncated. show original

yinxiuqu · 2021 年5 月 5 日 06:02

lsp-python-ms装好了，要怎么配置？高手们谁能给一段完整配置吗？

Voleking · 2021 年5 月 7 日 07:52

第一，你在 lsp-pyright 下面问废弃的 lsp-python-ms 咋用🤣；

第二，网上你搜 use-package lsy-pyright 一堆，或者几个主流流行配置文件都有，你不如直接抄。

yinxiuqu · 2021 年5 月 7 日 11:07

好的，谢谢你。

jesse · 2021 年5 月 8 日 00:01

大佬，pyright产生的typings目录可不可以指定别的名字，比如 _ _ typings _ _

seagle0128 · 2021 年5 月 8 日 02:39

Optionally specify a “stubPath” in your pyrightconfig.json file. This is where pyright will generate your type stub files. By default, the stubPath is set to “./typings”.

github.com

microsoft/pyright/blob/main/docs/type-stubs.md

## Type Stub Files

Type stubs are “.pyi” files that specify the public interface for a library. They use a variant of the Python syntax that allows for “...” to be used in place of any implementation details. Type stubs define the public contract for the library.

### Importance of Type Stub Files

Regardless of the search path, Pyright always attempts to resolve an import with a type stub (“.pyi”) file before falling back to a python source (“.py”) file. If a type stub cannot be located for an external import, Pyright will try to use inline type information if the module is part of a package that contains a “py.typed” file (defined in [PEP 561](https://www.python.org/dev/peps/pep-0561/)). If the module is part of a package that doesn’t contain a “py.typed” file, Pyright will treat all of the symbols imported from these modules will be of type “Unknown”, and wildcard imports (of the form `from foo import *`) will not populate the module’s namespace with specific symbol names.

Why does Pyright not attempt (by default) to determine types from imported python sources? There are several reasons.

1. Imported libraries can be quite large, so analyzing them can require significant time and computation.
2. Some libraries are thin shims on top of native (C++) libraries. Little or no type information would be inferable in these cases.
3. Some libraries override Python’s default loader logic. Static analysis is not possible in these cases.
4. Type information inferred from source files is often of low value because many types cannot be inferred correctly. Even if concrete types can be inferred, generic type definitions cannot.
5. Type analysis would expose all symbols from an imported module, even those that are not meant to be exposed by the author. Unlike many other languages, Python offers no way of differentiating between a symbol that is meant to be exported and one that isn’t.

If you’re serious about static type checking for your Python source base, it’s highly recommended that you consume “py.typed” packages or use type stub files for all external imports. If you are unable to find a type stub for a particular library, the recommended approach is to create a custom type stub file that defines the portion of that module’s interface used by your code. More library maintainers have started to provide inlined types or type stub files.

### Generating Type Stubs
If you use only a few classes, methods or functions within a library, writing a type stub file by hand is feasible. For large libraries, this can become tedious and error-prone. Pyright can generate “draft” versions of type stub files for you.

该文件已被截断。显示原文

jesse · 2021 年5 月 14 日 16:54

请问这是我配置的问题还是pyright不支持pep584？两个dict的value类型都是tuple，只不过一个长度1另一个长度2

Voleking · 2021 年6 月 10 日 12:33

我原来以为也是 pyright --createstub pandas 就行，最近遇到性能问题把 useLibraryCodeForTypes 关了才发现这样生成的 stubs 没法补全，比如下面这段代码：

import pandas as pd

d = {'col1': [1, 2], 'col2': [3, 4]}
df = pd.DataFrame(data=d)

相反从 GitHub - microsoft/python-type-stubs: A set of type stubs for popular Python packages. These are works in progress from the Microsoft Python team and others, with the intent that they are contributed to typeshed or to the associated packages once sufficiently complete. 这下的就可以

如果是这样感觉好鸡肋呀，不可能为所有 library 生成 stubs，useLibraryCodeForTypes 又有性能问题。

seagle0128 · 2021 年6 月 10 日 12:57

给微软提issue吧，这是server的问题，但是微软已经决定废弃mspyls，只能用pylance和pyright

Voleking · 2021 年6 月 10 日 14:49

提了，和我说这两个目的是不一样的😂 pyright --createstub cannot complete like useLibraryCodeForTypes · Issue #1970 · microsoft/pyright · GitHub