Skip to content

Conversation

@jakkdl
Copy link
Member

@jakkdl jakkdl commented Mar 3, 2023

Noticed due to open_nursery missing the strict_exception_types argument, but various other issues raised by stubtest also addressed to the best of my ability. If any of them are problematic, it's easy to chuck them into the allowlist instead.

It's very possible that a bunch of the missing stubs in the allowlist should be added to the stubs.

I have no clue why ci.sh creates an empty directory and symlinks in CHECK_TYPING, but whatever the reason I did the same for CHECK_STUBS.

@jakkdl jakkdl requested a review from Zac-HD March 3, 2023 12:28
Copy link
Member

@Zac-HD Zac-HD left a comment

Choose a reason for hiding this comment

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

One comment below, but this looks like a nice improvement over the status quo to me!

(I'd love for someone to look through the allowlist and decide whether we need any further fixes, but IMO that should not block this PR)

Comment on lines +88 to +93
def __init__(
self, exceptions: Sequence[BaseException], *, _collapse: bool = ...
): ...
def __new__(
cls: T, exceptions: Sequence[BaseException], *, _collapse: bool = ...
) -> T: ...
Copy link
Member

Choose a reason for hiding this comment

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

Probably better to not expose this param in stubs, since it's got a leading underscore and use of MultiError is deprecated anyway!

Copy link
Member Author

Choose a reason for hiding this comment

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

Hmm, it is just a stub - and not an official API/documentation. If there weren't a stub file, type checkers would see the parameters, and in error messages and the like you could see references to it. So I think I'm leaning towards keeping it.
I think having fewer lines in the allowlist also is a good thing.

Copy link
Member

Choose a reason for hiding this comment

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

I meant "have a stub for MultiError, which omits the _collapse parameter", I think we agree on the first part but I miscommunicated about the second?

Copy link
Member Author

Choose a reason for hiding this comment

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

Ah no that's how I interpreted you 😅 So the miscommunication must be on my part! :D

I think adding trio.MultiError.__init__ and trio.MultiError.__new__ to allowlist.txt isn't great. Another reason for keeping the stubs technically correct is to ease a transition away from having separate stub files at all, and if exposing _collapse is bad for some reason that should be addressed in trio - rather than hidden by having an "incorrect" type for the function in the stub.

@Zac-HD Zac-HD merged commit 6cefb0b into python-trio:master Mar 7, 2023
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

Successfully merging this pull request may close these issues.

2 participants