Update specification for directives for sys.implementation and sys.platform checks. by Josverl · Pull Request #2173 · python/typing

Josverl · 2026-02-12T17:25:30Z

This PR expands and clarifies the specification for version, platform, and Python implementation checks:

Adds checks for sys.implementation.name and sys.implementation.version.
Specifies supported comparisons, including in / not in with literal tuples, sets, and lists, and sys.platform.startswith().
Covers combining checks with and, or, and not.
Distinguishes required forms from optional extensions.
Adds examples and guidance on target configuration and defaults.

References :

python-cla-bot · 2026-02-12T17:25:36Z

All commit authors signed the Contributor License Agreement.

Josverl · 2026-02-22T13:00:56Z

I have updated the text to better clarify the exact comparisons for each of the supported attributes,
excluded the use of named attributes,
and did some more word-smithing to reduce unneeded verbosity.
I have also added highlighting to the examples, as a raiding aide.

Josverl · 2026-03-30T19:57:37Z

Dear TC,
Is there a decision on this PR yet, or have I missed a step in the process?

If so kindly let me know how to proceed.

JelleZijlstra

I'm generally supportive but I think this change needs some more editing, and I'd like support in at least some type checkers (at least an open PR) before we start mandating this pattern.

Josverl · 2026-08-09T19:58:39Z

Dear typing council,
I have been waiting patiently , but there seems to be no progress on this.
As far as I can see I have actioned - or responded - to all feedback,
Reviewers have not responded to the updates they requested. Eric has stepped down for the TC since - so that is understandable.

However now it appears that this PR is in a Catch-22 situation;
Waiting for One or more typecheckers to implement this - but for typecheckers to implement this it should be in the spec.

Lacking response I plan close this in a few weeks

davidhalter · 2026-08-09T21:57:25Z

Waiting for One or more typecheckers to implement this - but for typecheckers to implement this it should be in the spec.

This is not the case at all. It is very typical for type checkers to implement features even if they are not in the spec. It is very helpful to have feedback from type checker authors to be able to understand potential problems with spec changes.

I think this has worked quite well in the past.and if a feature is useful enough there is usually a type checker that will implement it.

carljm

Thanks for your patience, @Josverl. I'm not sure we've fully reached consensus yet on what should be supported here, but I also generally support making this clearly specified. I also think this still needs some editing to give a clear and unambiguous presentation of the requirements.

Josverl · 2026-08-10T21:40:51Z

Thanks all for the renewed attention and comments.

I'll try to clarify where I can do
and keep a list of topics that need a decision one way or another

Josverl · 2026-08-15T20:57:06Z

Again thanks for the feedback and suggestions to improve the spec.

I processed the comments and suggestion - and commented or marked them as resolved to keep track.
Please feel free to Unresolve or add additional comments as needed.
I have extended the Configuration section to help clarify how a type checker could be configured including default values or approaches for defaults.

Open topics.

1. 2-Tuple or 3-Tuple version comparisons.
see comments

requirement is for 2-Tuple checks
type checkers are allowed to also process 3-Tuple checks

2. Should in / not in membership checks use tuple, set or list.
intent was tuples, was updated to set , now waiting for consensus

* ``sys.platform in <tuple/set/list of string literals>``
* ``sys.platform not in <tuple/set/list of string literals>``
* ``sys.implementation.name in <tuple/set/listof string literals>``
* ``sys.implementation.name not in <tuple/set/list of string literals>``

3. Scope
as raised by @AlexWaygood
Is the scope of this change too large (it has grown since that comment) and should there be a implementation timeline / staged implementation.
I have refrained from answering this - as I am not the one that can do the implementation.

I think the commits should be squashed when merging - I've kept them separate for now.

carljm · 2026-08-17T21:16:26Z

We could eliminate open-question (2) and at least partially address (3) by just considering containment checks as out of scope to specify for now. Considering they don't add any new capability, just allow writing more concise code, they aren't really necessary. We could leave this out of the spec / conformance suite for now and up to individual type checkers. Similarly maybe for startswith. Leaving it out doesn't prevent type checkers from supporting it. And including it in the spec / conformance suite doesn't guarantee type-checker support, either, so it's unclear how soon some of these difficult-to-support patterns will be usable in practice anyway, even if they are included here.

jorenham · 2026-08-17T21:34:58Z

We could eliminate open-question (2) and at least partially address (3) by just considering containment checks as out of scope to specify for now. Considering they don't add any new capability, just allow writing more concise code, they aren't really necessary.

+1

Similarly maybe for startswith.

Unlike containment checks, startswith can't always be expressed using equality checks. For example sys.platform on FreeBSD on Python<3.14 includes the version number (docs) , so it can be "freebsd7", "freebsd8", ...., "freebsd15". This list will grow each two (?) years too. So if you want to check if you're on FreeBSD, you'll have to spell out each previous version + a bunch of future versions. So at least until Python 3.13 is EOL, I think that we should keep startswith.

Josverl · 2026-08-17T21:38:35Z

by just considering containment checks as out of scope to specify for now

That would be disappointing, especially as one of the first responses in May'25 in DPO included :

Supporting both in and not in operators is straightforward.

But reality is that there different opinions based on different considerations, and

.startwith() was added based on review comments. ~~More than happy to remove that to simplify matters.~~

Josverl · 2026-08-17T21:38:53Z

Not closed in anger - just a typo

Inline list and set membership tests now preserve the values of their individual elements, allowing ty to determine when a condition is always true or false. With the target platform set to Linux, both `sys.platform in ["linux", "windows"]` and `sys.platform in {"linux", "windows"}` select only the matching branch, so an assignment there is inferred as `Literal[1]`. Reuse the precise element extraction used for iteration and membership narrowing without changing the inferred container type. Lists and sets use the existing tuple membership equality evaluator, including its identity-or-equality behavior. For sets, assume equality is an equivalence relation and equal objects have equal hashes. Checking reflexive equality across union alternatives also improves existing tuple membership inference. Context is that in python/typing#2173 people are wanting to specify that `sys.platform in ["linux", "windows"]` should work. This makes it work in ty so that we can be fine with any outcome of that specification change. ## Test plan Mdtests cover platform-dependent branch reachability; positive and negative membership in inline lists and sets; inferred literal values and unions; fixed-length unpacking; stored mutable containers; custom equality and identity; comparison chains; and preservation of enum-set narrowing. ## Ecosystem report The comparison for head `90111f10da9359722abb903351b89aaae0f9bcba` adds four `redundant-condition-strict` warnings. The paasta and SciPy warnings correctly identify disjoint membership checks. The dd-trace-py warning exposes existing limitations in modeling dynamic `setattr`; the Scrapy warning exposes existing attribute narrowing across method calls and `await`. Equivalent equality checks already exhibit both limitations on the base revision. These existing limitations are accepted for this change. See the [full ecosystem report](#28676 (comment)) for minimized examples and exact comparison details.

Josverl · 2026-10-07T21:35:17Z

Just to avoid unneeded waiting:
I think I have responded to all review comments; but have not marked them as resolved (as earlier I was to eager to close)
Please let me know if further clarifications or updates are requested, or that things are clear.

Josverl · 2026-10-19T21:35:25Z

@carljm,
Sorry for the delay in addressing your latest suggestions & comments.

CI also seems to have forgotten that I did sign the CLA with all my identities, re-signing is not possible either.
Not sure what I can do about that.

carljm

I think the CLA signing failure is because your latest commit (unlike the previous ones) is authored by Jos_Verlinde@hotmail.com, which GitHub can't associate with your GitHub account. If you can amend that commit with a recognized email address and force push, I suspect the CLA signing check will pass.

Barring my two nits below, I think this PR is ready for conformance tests. @jorenham @davidhalter @JelleZijlstra @rchen152 any objections to the spec updates here, before @Josverl writes conformance tests?

jorenham · 2026-10-20T08:19:44Z

I'll try to take a look this evening

jorenham

Looks good overall, thanks. I left some comments for some minor issues / nits / suggestions.

jorenham · 2026-10-20T19:26:51Z

+Required forms and optional extensions
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Type checkers must support the forms specified above as required. Support for additional 


consistency nit

Suggested change

Type checkers must support the forms specified above as required. Support for additional

Type checkers should support the forms specified above as required. Support for additional

I do not think that "should" can be combined with "required" in this sentence.
That would degrade the meaning of the "required" statements in the prior paragraphs, which I think is incorrect.

IMO you should just drop the sentence. The spec is clear in the "above" cases where a type checker has to support it and where it's optional, so the sentence feels unnecessary.

Dropped that sentence and reduced the section heading to: Optional extensions

Josverl · 2026-10-26T10:57:19Z

@carljm, @jorenham
I have addressed the last few review comments,
and have now I squashed the different edits and rebased on current master.

Also have tried to make a start on the conformance tests in #2375.
Lets continue the conversation there.

CLA signature appears to have been caused by some parts of the CLA check assuming that smtp e-mail addresses are case sensitive, but that was solved simply.

carljm · 2026-10-26T17:31:27Z

@Josverl Why do we need to do conformance tests in a separate PR? I would find it much easier to review, approve, and merge the spec changes and conformance tests together, in the same PR. Conformance tests may reveal changes that we need to make to the spec, and we need to ensure they are consistent with each other.

Josverl · 2026-10-26T20:45:46Z

@Josverl Why do we need to do conformance tests in a separate PR? I would find it much easier to review, approve, and merge the spec changes and conformance tests together, in the same PR. Conformance tests may reveal changes that we need to make to the spec, and we need to ensure they are consistent with each other.

Why do we need to do conformance tests in a separate PR

The original plan I was set out on was much simpler, and I explicitly started out with: "This is my first post to the Python discuss, so please be gentle."

And was guided by the TC decision process that documents:

After at least a week, the Council will make a decision, which may be to accept the change, reject it, or modify it.

This is my first PR to "the big" Python, it is open more than 10 months with over 150 comments,

the scope has significantly increased beyond my original intent
it is also more complete and (much) better formulated.

to be very clear, I could not have done this without all your help, but it has taken over 17 months since first discussion. ( with time-gaps both from all involved)
For me this has long passed the simple stage, Instead it feels like I am lifting weight above my class, with little guidance on the process.

On the conformance tests I replied earlier :

Makes sense to me, but TBH I personally would need to study how to define these, And happy to do that either in this PR or as a follow-up , but perhaps agree on the 'rules' first

So what are the rules for creating conformance test , for functionality that is not currently supported ?
I have read the paragraph that explains that in the repo a few times. that explains how to add a single test for existing functionality.

Note that the TC process document does not mention conformance test.
To me, the most logical order would be :

discuss the spec, write the spec , approve the spec , update the tools, test the conformance.
I do see your point in needing to change that , but

To extend beyond that, is perhaps apparent you. To me it is not.

Yes, I can and have set an AI to work, and revised the results to avoid the most apparent mistakes.
The tests seem OK , and a HTML page is produced.
But I have limited trust in the result , and that is why that PR is marked explicitly as Draft.

What is the process after that ?
If that is waiting for all tools to adopt and update the results per feature per tool then I am unable to estimate the wall-time.
If that means another X months then please allow me to be honest; to me that is a too much to ask for a first PR.

So that is why I split them , because I would not want to loose this part, and currently I am unable to commit to finish something that I cannot fully understand the implications of.

I would welcome a conversation on the challenges and opportunities involved in a more private setting.

JelleZijlstra · 2026-10-26T21:08:25Z

@Josverl are you on Discord? I'd be happy to connect there and talk through issues in a more informal way. (I can't speak for Carl but he's also on Discord and might also be willing to chat there.)

Josverl · 2026-10-27T02:25:22Z

are you on Discord

Yes, thanks for the offer.

I shared my details via E-mail.

carljm · 2026-10-27T04:53:58Z

Yes, happy to discuss in Discord!

To answer a few specific questions/comments:

Reducing scope of a change to the spec is almost never a problem, IMO; if you would prefer to reduce scope of this change closer to your original scope so as to make it feel more manageable, feel very free to do so! Though it seems maybe we've by now done the work and reached agreement on the current scope, so it no longer makes sense to reduce.
I haven't done a detailed review yet, but at first glance the approach you are taking on the conformance tests looks good to me!
Implementation in type checkers is not a pre-requisite to changing the conformance suite. Only review and approval of the spec and conformance suite changes. This will mark every type checker as out of conformance on the new test file for now, but that's fine.

davidhalter

First of all, thank you @Josverl for staying on this for such a long time. This is one of the most discussed issues and it's easy to give up at some point. Also thank you to Carl for doing most of the review work.

The PR is in a very good shape IMO. I have a few questions that are directed to other people than @Josverl, and a small suggestion to drop a sentence, otherwise no work should be necessary.

I would definitely not reduce the scope for now. While I would be grateful for conformance tests here I'd rather merge it as is and do the conformance tests later if @Josverl decides to not work on this anymore, since I think it's in a really good state and a massive improvement from the previous version. Though if you @Josverl still have some energy left in the tank, conformance tests would of course be awesome. :)

Thanks all!

davidhalter · 2026-10-27T08:02:56Z

+^^^^^^^^^^^^^^
+
+Type checkers may optionally support comparisons of ``os.name`` with string
+literals.


Why is this optional? Sorry I haven't followed the discussion for a while and I'm sure it has been discussed. It might make sense to make this mandatory as well.

Because it's currently optional in the the conformance suite:

typing/conformance/tests/directives_version_platform.py

Lines 61 to 75 in d06c5dd

if os.name == "bogus_os":

val10 = ""

else:

val11 = ""

this_raises = val10 # E?: `val10` is undefined, but support for `os.name` is optional

does_not_raise = val11 # E? should not error if `os.name` control flow is supported, but might be flagged as possibly undefined otherwise

if os.name != "bogus_os":

val12 = ""

else:

val13 = ""

does_not_raise = val12 # E?: should not error if `os.name` control flow is supported, but might be flagged as possibly undefined otherwise

this_raises = val13 # E?: `val13` is undefined, but support for `os.name` is optional

Thanks! IMO we should probably make that mandatory then in a separate follow up PR.

davidhalter · 2026-10-27T08:06:42Z

+Required forms and optional extensions
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Type checkers must support the forms specified above as required. Support for additional 


IMO you should just drop the sentence. The spec is clear in the "above" cases where a type checker has to support it and where it's optional, so the sentence feels unnecessary.

davidhalter · 2026-10-27T08:22:52Z

+The configuration options should allow users to specify the target values for these
+symbols, so that type checkers can evaluate the version and platform checks
+correctly. The exact mechanism and names for these configuration options are
+implementation-specific and defined by each type checker.


This is more of a question to other type checker authors: Is this already implemented somewhere? I definitely like that sys.implementation.name is added, that seems like a very useful addition especially in stubs. The implementation version is probably also needed, but that asks the question: How should I infer the implementation version? Should I just default to a nullable sys.implementation.version if the implementation cpython is not used and the version is not provided?

IMO it would be nice if we added this to the conformance tests as well, but that might be a little more complicated since we would need a way to specify the implementation/version for a specific test file. So I don't think this is necessary for this PR, but I would definitely appreciate if someone of us (looking at myself as well) would do the work here.

…atform checks. Signed-off-by: Jos Verlinde <jos_verlinde@hotmail.com>

Signed-off-by: Jos Verlinde <jos_verlinde@hotmail.com>

…checks. - Introduced new TOML files for various conformance results related to directives implementation version, platform checks, and version/platform boolean checks. - Marked conformance as "Unsupported" or "Partial" based on the ability to prune branches for specific checks. - Documented unexpected errors and output related to type assignment issues, particularly with `Literal` types and incompatible types in assignments. - Updated existing TOML files to include additional error messages for unresolved references and type assertion failures. Signed-off-by: Jos Verlinde <jos_verlinde@hotmail.com>

Signed-off-by: Jos Verlinde <jos_verlinde@hotmail.com>

Copilot

🟡 Changes recommended

Stale mypy and ty overrides understate passing platform-check results, while the documentation incorrectly lists Android and iOS as Python implementations.

3 open issues

What changed in this PR

This PR expands the typing specification’s rules for version, platform, and implementation checks, helping type checkers handle platform-specific code and non-CPython implementations consistently.

Changes:

Defines supported comparisons, Boolean combinations, optional extensions, and target configuration defaults.
Adds conformance tests for implementation checks, platform membership and prefixes, and version boundaries.
Records results for six type checkers and updates the conformance report and testing guidance.

File	Description
`docs/spec/directives.rst`	Expands the specification and examples.
`conformance/tests/directives_version_platform.py`	Adds boundary and branch-selection tests; clarifies comments.
`conformance/tests/directives_version_platform_boolean.py`	Tests Boolean combinations of checks.
`conformance/tests/directives_platform_checks.py`	Tests platform comparisons, membership, and prefixes.
`conformance/tests/directives_implementation_version.py`	Tests CPython implementation-version defaults.
`conformance/tests/directives_implementation_name.py`	Tests implementation-name equality and membership.
`conformance/results/zuban/directives_version_platform.toml`	Updates Zuban version-check diagnostics.
`conformance/results/zuban/directives_version_platform_boolean.toml`	Records Zuban Boolean-check results.
`conformance/results/zuban/directives_platform_checks.toml`	Records Zuban platform-check results.
`conformance/results/zuban/directives_implementation_version.toml`	Records Zuban implementation-version results.
`conformance/results/zuban/directives_implementation_name.toml`	Records Zuban implementation-name results.
`conformance/results/ty/directives_version_platform.toml`	Updates ty version-check diagnostics.
`conformance/results/ty/directives_version_platform_boolean.toml`	Records ty Boolean-check results.
`conformance/results/ty/directives_platform_checks.toml`	Records ty platform-check results.
`conformance/results/ty/directives_implementation_version.toml`	Records ty implementation-version results.
`conformance/results/ty/directives_implementation_name.toml`	Records ty implementation-name results.
`conformance/results/results.html`	Adds result rows and updates summary scores.
`conformance/results/pyright/directives_version_platform.toml`	Updates Pyright version-check diagnostics.
`conformance/results/pyright/directives_version_platform_boolean.toml`	Records Pyright Boolean-check results.
`conformance/results/pyright/directives_platform_checks.toml`	Records Pyright platform-check results.
`conformance/results/pyright/directives_implementation_version.toml`	Records Pyright implementation-version results.
`conformance/results/pyright/directives_implementation_name.toml`	Records Pyright implementation-name results.
`conformance/results/pyrefly/directives_version_platform.toml`	Updates Pyrefly version-check diagnostics.
`conformance/results/pyrefly/directives_version_platform_boolean.toml`	Records Pyrefly Boolean-check results.
`conformance/results/pyrefly/directives_platform_checks.toml`	Records Pyrefly platform-check results.
`conformance/results/pyrefly/directives_implementation_version.toml`	Records Pyrefly implementation-version results.
`conformance/results/pyrefly/directives_implementation_name.toml`	Records Pyrefly implementation-name results.
`conformance/results/pycroscope/directives_version_platform.toml`	Updates Pycroscope version-check diagnostics.
`conformance/results/pycroscope/directives_version_platform_boolean.toml`	Records Pycroscope Boolean-check results.
`conformance/results/pycroscope/directives_platform_checks.toml`	Records Pycroscope platform-check results.
`conformance/results/pycroscope/directives_implementation_version.toml`	Records Pycroscope implementation-version results.
`conformance/results/pycroscope/directives_implementation_name.toml`	Records Pycroscope implementation-name results.
`conformance/results/mypy/directives_version_platform.toml`	Updates mypy version-check diagnostics.
`conformance/results/mypy/directives_version_platform_boolean.toml`	Records mypy Boolean-check results.
`conformance/results/mypy/directives_platform_checks.toml`	Records mypy platform-check results.
`conformance/results/mypy/directives_implementation_version.toml`	Records mypy implementation-version results.
`conformance/results/mypy/directives_implementation_name.toml`	Records mypy implementation-name results.
`conformance/README.md`	Documents test targets, scenarios, and coverage limitations.

_{Review effort: Balanced}

+conformant = "Partial"
+notes = """
+Does not prune branches for tuple, set, or list membership and nonmembership checks.


+conformant = "Partial"
+notes = """
+Does not prune branches for set or list membership and nonmembership checks; tuple checks pass.


Josverl · 2026-10-30T21:47:50Z

+Default value: ``"cpython"``, unless configured otherwise.
+
+Common values: ``"cpython"``, ``"pypy"``, ``"micropython"``, ``"graalpy"``,
+``"android"``, ``"ios"``, ``"ironpython"``


@jorenham , IIRC these were suggested by you.
What is your take on this ?

Ah yea sorry I intended to suggest adding ios and android to sys.platform, but when writing about the dubious jython value here I apparently ended up suggesting adding ios and android here instead.

Josverl · 2026-10-30T21:49:42Z

I have no intent of abandoning this,
but it has been a long stretch, and I desire(d) clarity on the remaining work.

I have merged the conformance tests and rebased
( and now It seems that I also activated a copilot self-review 🫥 )

Would still appreciate assistance wrt to the conformance tests to make sure they are correct.

Unclear why RTD cannot checkout the commit.

Josverl mentioned this pull request Feb 12, 2026

Spec Change : Additional detail and option for platform checks. python/typing-council#52

Open

4 tasks

carljm requested changes Feb 12, 2026

View reviewed changes

Comment thread docs/spec/directives.rst Resolved

Comment thread docs/spec/directives.rst Resolved

Comment thread docs/spec/directives.rst Resolved

Comment thread docs/spec/directives.rst Resolved

Comment thread docs/spec/directives.rst Resolved

Comment thread docs/spec/directives.rst Resolved

erictraut requested changes Feb 14, 2026

View reviewed changes

Comment thread docs/spec/directives.rst Resolved

Comment thread docs/spec/directives.rst Resolved

Comment thread docs/spec/directives.rst Resolved

Comment thread docs/spec/directives.rst Resolved

Comment thread docs/spec/directives.rst Resolved

srittau added the topic: typing spec For improving the typing spec label Feb 20, 2026

Josverl force-pushed the specs/sys.implementation.name branch 2 times, most recently from 4151e84 to d7fbb9e Compare February 21, 2026 17:09

JelleZijlstra reviewed Feb 21, 2026

View reviewed changes

Comment thread docs/spec/directives.rst Resolved

Comment thread docs/spec/directives.rst Resolved

Comment thread docs/spec/directives.rst Resolved

Comment thread docs/spec/directives.rst Resolved

Josverl force-pushed the specs/sys.implementation.name branch from d7fbb9e to 62d90dc Compare February 22, 2026 12:56

Josverl force-pushed the specs/sys.implementation.name branch from 62d90dc to ff338e3 Compare February 22, 2026 13:08

AlexWaygood reviewed Feb 22, 2026

View reviewed changes

Comment thread docs/spec/directives.rst Resolved

Josverl commented Feb 22, 2026

View reviewed changes

Comment thread docs/spec/directives.rst Resolved

JelleZijlstra reviewed Mar 30, 2026

View reviewed changes

Comment thread docs/spec/directives.rst Resolved

Josverl force-pushed the specs/sys.implementation.name branch from c575c15 to c951b00 Compare April 3, 2026 19:21

Josverl requested review from carljm and erictraut April 3, 2026 19:23

jorenham reviewed Aug 9, 2026

View reviewed changes

Comment thread docs/spec/directives.rst Resolved

Comment thread docs/spec/directives.rst Resolved

Comment thread docs/spec/directives.rst Resolved

Comment thread docs/spec/directives.rst Resolved

carljm reviewed Aug 10, 2026

View reviewed changes

Josverl force-pushed the specs/sys.implementation.name branch from b3b76c1 to 98e3697 Compare August 15, 2026 20:18

Josverl closed this Aug 17, 2026

carljm reviewed Sep 16, 2026

View reviewed changes

carljm mentioned this pull request Sep 17, 2026

[ty] Infer constant membership in inline list and set literals astral-sh/ruff#28676

Merged

carljm reviewed Oct 7, 2026

View reviewed changes

carljm reviewed Oct 20, 2026

View reviewed changes

Comment thread docs/spec/directives.rst Resolved

Comment thread docs/spec/directives.rst Resolved

jorenham reviewed Oct 20, 2026

View reviewed changes

Josverl force-pushed the specs/sys.implementation.name branch 2 times, most recently from bc8965e to d2c4133 Compare October 23, 2026 13:19

Josverl mentioned this pull request Oct 23, 2026

conformance: Add conformance tests for implementation and platform checks. #2375

Closed

Josverl force-pushed the specs/sys.implementation.name branch from d2c4133 to e612515 Compare October 26, 2026 10:53

davidhalter reviewed Oct 27, 2026

View reviewed changes

Josverl added 5 commits October 30, 2026 22:21

Update specification for directives for sys.implementation and sys.pl…

b8ff527

…atform checks. Signed-off-by: Jos Verlinde <jos_verlinde@hotmail.com>

Add additional version or platform conformance tests.

54b4d7b

Signed-off-by: Jos Verlinde <jos_verlinde@hotmail.com>

Document version and platform checking conformance approach.

b558039

Signed-off-by: Jos Verlinde <jos_verlinde@hotmail.com>

Update conformance results.html

70ac79f

Signed-off-by: Jos Verlinde <jos_verlinde@hotmail.com>

Josverl force-pushed the specs/sys.implementation.name branch from e612515 to 70ac79f Compare October 30, 2026 21:36

Copilot AI balanced review requested due to automatic review settings October 30, 2026 21:36

Copilot started reviewing on behalf of Josverl October 30, 2026 21:37

View session

Copilot AI reviewed Oct 30, 2026

View reviewed changes

	Type checkers must support the forms specified above as required. Support for additional
	Type checkers should support the forms specified above as required. Support for additional

	if os.name == "bogus_os":
	val10 = ""
	else:
	val11 = ""

	this_raises = val10 # E?: `val10` is undefined, but support for `os.name` is optional
	does_not_raise = val11 # E? should not error if `os.name` control flow is supported, but might be flagged as possibly undefined otherwise

	if os.name != "bogus_os":
	val12 = ""
	else:
	val13 = ""

	does_not_raise = val12 # E?: should not error if `os.name` control flow is supported, but might be flagged as possibly undefined otherwise
	this_raises = val13 # E?: `val13` is undefined, but support for `os.name` is optional

Conversation

Josverl commented Feb 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

python-cla-bot Bot commented Feb 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Josverl commented Feb 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Josverl commented Mar 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

JelleZijlstra left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Josverl commented Aug 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

davidhalter commented Aug 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

carljm left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Josverl commented Aug 10, 2026

Uh oh!

Josverl commented Aug 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

carljm commented Aug 17, 2026

Uh oh!

jorenham commented Aug 17, 2026

Uh oh!

Josverl commented Aug 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Josverl commented Aug 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Josverl commented Feb 12, 2026 •

edited

Loading

python-cla-bot Bot commented Feb 12, 2026 •

edited

Loading

Josverl commented Feb 22, 2026 •

edited

Loading

Josverl commented Mar 30, 2026 •

edited

Loading

Josverl commented Aug 9, 2026 •

edited

Loading

davidhalter commented Aug 9, 2026 •

edited

Loading

Josverl commented Aug 15, 2026 •

edited

Loading

Josverl commented Aug 17, 2026 •

edited

Loading

Josverl commented Aug 17, 2026 •

edited

Loading

Josverl commented Oct 19, 2026 •

edited

Loading

Josverl commented Oct 26, 2026 •

edited

Loading