Closed microbit-matt-hillsdon closed 2 years ago
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.
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
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 😄
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.
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/