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

mypy==0.991#202

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
altendky wants to merge10 commits intomaster
base:master
Choose a base branch
Loading
frommypy_0.991
Open

mypy==0.991#202

altendky wants to merge10 commits intomasterfrommypy_0.991

Conversation

@altendky
Copy link
Collaborator

No description provided.

@bluebird75
Copy link
Collaborator

This version of mypy is not released for Python 3.6 . So we need to add a conditional, one way or the other...

Apart from that, we can also search which was the first version that was broken by our stubs. I don't have much time right now for this, though.

@altendky
Copy link
CollaboratorAuthor

Locally here in Linux, 0.940 is the first version toSIGSEGV. With 0.960 through 0.991 I get a few messages first but then they alsoSIGSEGV.python/mypy@a9c62c5 acts similar to 0.991. There are messages followed by aSIGSEGV, though there's an additional message. Seepython/mypy#14196.

"pytest",
"pytest-xvfb",
],
},
Copy link
Collaborator

Choose a reason for hiding this comment

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

I did not know you can do things like this. Nice!

Copy link
CollaboratorAuthor

Choose a reason for hiding this comment

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

See theenv_var list athttps://peps.python.org/pep-0508/.

env_var       = ('python_version' | 'python_full_version' |                 'os_name' | 'sys_platform' | 'platform_release' |                 'platform_system' | 'platform_version' |                 'platform_machine' | 'platform_python_implementation' |                 'implementation_name' | 'implementation_version' |                 'extra' # ONLY when defined by a containing layer                 )

Though it appears this boundary may belong closer to 0.981python/mypy@dc118e2.

@bluebird75
Copy link
Collaborator

I am convinced that we should have a very stable mypy for our tests, and one CI job with failure allowed for testing latest mypy.

Until this is fixed, 0.930 is our good version then.

@altendky
Copy link
CollaboratorAuthor

Dependabot style automatic PRs are an alternative to consider instead of having 'latest version' jobs. But, there are upsides to all of various approaches to this.

Reported the segfault upstream.https://www.riverbankcomputing.com/pipermail/pyqt/2022-November/045068.html I'll take a look at a stubtest wrapper that monkey patches to disable the class finality test.

@altendky
Copy link
CollaboratorAuthor

segfaults gone... now just 2853 regular stubtest errors. Hopefully my comments around the dependency versions insetup.py are sufficient to have a clue about what we're stuck on here.

@bluebird75
Copy link
Collaborator

At least it passes with Python 3.6

@altendky
Copy link
CollaboratorAuthor

Note that there's mypy 1.0 now as well. Depending, it may be better to work this intermediate step, or may be better to just get to 1.0 directly.

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

Reviewers

@bluebird75bluebird75bluebird75 left review comments

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@altendky@bluebird75

[8]ページ先頭

©2009-2025 Movatter.jp