fix the length of platform.uname_result

[tungol]

It should be a 6-tuple, once processor is added. This makes sure mypy understands that.

Fixes #13064

[tungol]

This seems to work as expected.

[srittau]

Wow, what a hacky (upstream) class ... I wonder whether it's a better idea to just use the else branch for both versions, considering that the hacks are probably meant to emulate a six-field namedtuple. This means that the special-casing of namedtuple in type checkers could work better. Although we probably need to override __init__ in that case ...

In any case, I think we should add test cases for this.

[tungol]

I couldn't figure out a way to re-create the exact failure from the daily test in the regression test. Is there any way to do a regression test stub right now? Is that something that might be useful for other cases as well?

The regression test shows that mypy accepts the tuple[str, str, str, str, str, str] but pyright is ignoring it, so we may need a different solution.

[tungol]

I opened a discussion topic for the difference between mypy and pyright in this case: https://discuss.python.org/t/conflicting-tuple-base-classes/72038

[tungol]

I don't like how many ignores this needs. But it does satisfy both mypy and pyright, and should fix the daily test failure.

[JelleZijlstra]

Why do we need the _uname_result_base class?

[tungol]

It's not adding much at this point. Here's a version without it.

[JelleZijlstra]

Thanks, this version seems cleaner

[github-actions]

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉

[tungol]

This solution gets uname_result to be pretty accurate by pushing the inaccuracies into _uname_result_base. I think that's a good tradeoff to make; it's close to the runtime, clears all allowlist entries (because we don't test the hidden base class) and it only needs the one ignore.

[AlexWaygood]

Thanks @tungol!