Type stubs for single-file top-level modules
Chưa có ai nhận issue này.
- Ngôn ngữ chính
- Python
- Star
- 1.8k
- Fork
- 302
- Merge trung bình
- 23 giờ
- Pull request đã merge (30 ngày)
- 8
Mô tả
PEP 561 currently states the following:
Package maintainers who wish to support type checking of their code MUST add a marker file named
py.typedto their package supporting typing.
I consider this requirement to be problematic for Python libraries that are written in another programing language and distributed as compiled .so files. PEP 561 currently does not provide a way to mark .so files residing directly in site-packages/ to be typed, resulting in typed shared libraries needing to introduce an intermediary __init__.py file such as the following:
from ._native import *
__doc__ = _native.__doc__
if hasattr(_native, "__all__"):
__all__ = _native.__all__
While this works for static type checkers I think this is obviously suboptimal because it has several undesired side-effects. Let's take the following as an example:
site-packages
├── my_project
│ ├── __init__.py
│ ├── _native.cpython-36m-x86_64-linux-gnu.so
│ └── py.typed
The unintended side-effects are:
- You can import
my_project._native. _nativeshows up in the documentation generated by pydoc. E.g. under PACKAGE CONTENTS for the documentation ofmy_projectand invoking e.g.help(my_project.foobar)will tell you thatfoobarresides in the modulemy_project._native.my_project.__file__now is the__init__.pyfile instead of the.sofile, potentially misleading developers into thinking the package is implemented in Python
So I really think PEP 561 should be amended to provide some way of marking single-file packages as "typed" without having to resort to hacks such as defining an intermediary __init__.py since that introduces a bunch of undesired side-effects that have the potential to confuse API users.
What do you think about this?
Hướng dẫn đóng góp
Chưa lập chỉ mục được hướng dẫn đóng góp cho kho mã nguồn này
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Hướng nghiên cứu
Bắt đầu bằng việc đọc PEP 561 và các ví dụ trong issue về các module được biên dịch thành một file, sau đó so sánh hành vi được nêu với cách pydoc báo cáo nội dung package và file. Hoàn thành khi đề xuất và ghi lại tài liệu về một cách được chấp nhận để đánh dấu các module .so được cài đặt trực tiếp là có kiểu, mà không cần các tác động phụ trung gian của init.py.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Đánh giá
- Công nghệ
- python
- Lĩnh vực
- documentation
- Loại issue
- Tính năng
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức độ hoạt động
- Ít trao đổi
- Độ rõ ràng
- Khá rõ ràng
- Mức phù hợp với người mới
- 38/100