Fix os.uname return value.

[microbit-matt-hillsdon]

Simpler than typeshed as on MicroPython it doesn't seem to be a structseq/namedtuple.

I'd prefer to match the @property approach as it communicates that there is a relationship between the tuple data and the fields but I think it's worth dropping this so it works well in the editor API panel. I raised https://github.com/microbit-foundation/python-editor-next/issues/741 to track the limitation there.

In CPython os.uname_result actually exists. In MicroPython it does not (actual type is tuple), but I can't see a reasonable way to type it without introducing a type for its return value.

See https://github.com/microbit-foundation/python-editor-next/issues/740 which has REPL output and a link to typeshed.

Editor PR: https://github.com/microbit-foundation/python-editor-next/pull/743 Editor demo: https://review-python-editor-next.microbit.org/os-uname/

[microbit-carlos]

Simpler than typeshed as on MicroPython it doesn't seem to be a structseq/namedtuple. ... In CPython os.uname_result actually exists. In MicroPython it does not (actual type is tuple), but I can't see a reasonable way to type it without introducing a type for its return value.

I thought it was meant to be a namedtuple, but you are right that type(os.uname() is actually <class 'tuple'> even thought it behaves like a namedtuple 🤔 Is this worth raising in MicroPython?

I'd prefer to match the @property approach as it communicates that there is a relationship between the tuple data and the fields but I think it's worth dropping this so it works well in the editor API panel. I raised https://github.com/microbit-foundation/python-editor-next/issues/741 to track the limitation there.

I guess we could not use @property until the Editor can process it and then change it back once that has been implemented in the Editor. But up to you what you think it's best.

[microbit-carlos]

Btw, for related info, it looks like using os.uname() might be deprecated in the future and we might want to start using sys.implementation and sys.version at some point: https://github.com/micropython/micropython/pull/8572

[microbit-matt-hillsdon]

Btw, for related info, it looks like using os.uname() might be deprecated in the future and we might want to start using sys.implementation and sys.version at some point: micropython/micropython#8572

Thanks. These at least appear to be correctly typed 😄

[microbit-matt-hillsdon]

I thought it was meant to be a namedtuple, but you are right that type(os.uname() is actually <class 'tuple'> even thought it behaves like a namedtuple 🤔 Is this worth raising in MicroPython?

Given your comment above about the future of os.uname I'm not sure it's worth it, but no strong view.