Jason R. Coombs added the comment:
For posterity, I'll share my motivation.
> Why is it a problem that people are using something which is documented as a
> tuple?
It's not a problem that they access it by tuple if it's documented.
The problem is that it's documented for access as a tuple w
Marc-Andre Lemburg added the comment:
I am closing this issue, since deprecations should really only be used when no
other means are possible.
The namedtuples returned by platform.uname() do support index access and so any
implementation change altering this is surprising and backwards incom
Steven D'Aprano added the comment:
You have given no justification for removing item access for the fields except
"some users are still relying on ... access by item position and length".
Normally the fact that some people are doing this would be reason to reject
this backwards-compatibility
Jason R. Coombs added the comment:
In issue40570, Marc-Andre writes:
> I don't think that deprecating standard tuple access is an option
for the uname() return value, since it's documented to be a tuple.
My thinking here is that as part of the deprecation, the documentation would be
updated
Jason R. Coombs added the comment:
In https://github.com/jaraco/cpython/tree/bc73729eb9, I started drafting a
proposed implementation to address this concern, but ran into a snag - the
tests immediately reveal that `tuple(platform.uname())` invokes `__len__`,
triggering the deprecation warni
New submission from Jason R. Coombs :
In issue40570, I learned that some users are still relying on legacy tuple-like
behaviors of `platform.uname()`, namely the access by item position and length:
```
platform.uname()[0]
len(platform.uname())
```
I propose to deprecate these behaviors and co
