Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

gh-132888: Fix Windows API error checking in pyrepl.windows_console#144248

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Open
aisk wants to merge6 commits intopython:main
base:main
Choose a base branch
Loading
fromaisk:windows-console-error

Conversation

@aisk
Copy link
Contributor

@aiskaisk commentedJan 26, 2026
edited by bedevere-appbot
Loading

WaitForSingleObject.argtypes= [HANDLE,DWORD]
WaitForSingleObject.restype=DWORD

OutHandle=GetStdHandle(STD_OUTPUT_HANDLE)
Copy link
Member

Choose a reason for hiding this comment

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

GetStdHandlecan returnINVALID_HANDLE_VALUE and should be checked, too?

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

This is at the top level of the file, so it will be executed when importing this module. Therefore, we can't raise an exception here. What we can do is check if the result isINVALID_HANDLE_VALUE and set it toNone or zero.

We will pass theOutHandle to other Windows APIs, likeReadConsoleInput. There, we will check the result and raise an exception usingget_last_error().

However, if we don't check the result and just keep it asINVALID_HANDLE_VALUE, the whole process won't change. KeepingINVALID_HANDLE_VALUE might actually be a better choice, since 0 may be valid in some situations. That's why MS introducedINVALID_HANDLE_VALUE instead of using zero.

Therefore, I think it's better to just keep the current implementation.

chris-eibl reacted with thumbs up emoji
Copy link
Member

Choose a reason for hiding this comment

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

I agree to all your points 👍

aisk reacted with laugh emoji
@chris-eibl
Copy link
Member

chris-eibl commentedJan 26, 2026
edited
Loading

In general this lgtm. I've built locally and did a few very basic manual tests like redirecting stdout / stderr.
The changes whereraise WinError(GetLastError()) are replaced withraise WinError(get_last_error()) are definitely ok, because we've also raised before and now won't just show the misleading

OSError: [WinError 0] The operation completed successfully.

anymore (#132962 (comment)).

But turning the silent swallowing into raising exceptions might bite us (although most probably the right thing to do), like you've seen in the failing tests in headless mode.

Most probably the swallowing just let another error surface slightly later, anyway, so I think it is ok to fail early and loud?

@aisk
Copy link
ContributorAuthor

In general this lgtm. I've built locally and did a few very basic manual tests like redirecting stdout / stderr. The changes whereraise WinError(GetLastError()) are replaced withraise WinError(get_last_error()) are definitely ok, because we've also raised before and now won't just show the misleading

OSError: [WinError 0] The operation completed successfully.

anymore (#132962 (comment)).

But turning the silent swallowing into raising exceptions might bite us (although most probably the right thing to do), like you've seen in the failing tests in headless mode.

Most probably the swallowing just let another error surface slightly later, anyway, so I think it is ok to fail early and loud?

Hi, thank you for your review. I'm quite unsure whether we should throw the error early during initialization, but since this is a private module and its main usage is in an environment with a console, and the error is just raised when there is no console, I think it's acceptable to raise the error early

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@chris-eiblchris-eiblchris-eibl left review comments

@ambvambvAwaiting requested review from ambvambv is a code owner

@pablogsalpablogsalAwaiting requested review from pablogsalpablogsal is a code owner

@lysnikolaoulysnikolaouAwaiting requested review from lysnikolaoulysnikolaou is a code owner

Assignees

No one assigned

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@aisk@chris-eibl

[8]ページ先頭

©2009-2026 Movatter.jp