This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Deprecate numeric item access for platform.uname()
Type: enhancement Stage: resolved
Components: Versions:
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: jaraco, lemburg, steven.daprano
Priority: normal Keywords:

Created on 2020-05-09 14:06 by jaraco, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Messages (6)
msg368517 - (view) Author: Jason R. Coombs (jaraco) * (Python committer) Date: 2020-05-09 14:06
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 constrain the supported interface to the following:

```
platform.uname().attribute
items = tuple(platform.uname())
```

In other words, the `uname_result` would only support access of the items by attribute or iteration of all attributes.

Any users wishing to access items by position or to calculate the length of the result would need to explicitly construct a tuple from the result.
msg368524 - (view) Author: Jason R. Coombs (jaraco) * (Python committer) Date: 2020-05-09 14:33
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 warning... so deprecating it while supporting `tuple(result)` may not be possible.
msg368537 - (view) Author: Jason R. Coombs (jaraco) * (Python committer) Date: 2020-05-09 19:23
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 to reflect the recommended and long-term supported usage (attribute access + iterability), including the recommended way to adapt if one wants a tuple. The guidance would eliminate or indicate as deprecated the index-based access. Then, by way of the DeprecationWarning, those still relying on item-access would be encouraged to update their implementation to use the preferred form. 


By doing this, `platform` goes from having 3 right ways to do something:

```
system = platform.system()
system = platfurm.uname().system
system = platform.uname()[0]
```

to just the first two.

I don't see how documenting something makes it permanent, though I acknowledge it does affect how one approaches any deprecation.
msg368551 - (view) Author: Steven D'Aprano (steven.daprano) * (Python committer) Date: 2020-05-09 22:27
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 breaking change. Why is it a problem that people are using something which is documented as a tuple as a tuple?
msg368766 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2020-05-13 08:03
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 incompatible, potentially breaking existing code which makes reasonable use of the index interface (the namedtuple and processor attribute was introduced in Python 3.3, so code written for prior versions may well still use the perfectly reasonable index approach).

You are essentially suggesting to change the return type, since you want to remove a standard tuple interface.
msg388140 - (view) Author: Jason R. Coombs (jaraco) * (Python committer) Date: 2021-03-05 01:10
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 when there is a superior method to access (by attribute) that's less opaque than the historical method by index.

I apologize for not documenting that in the original post. It seemed obvious to me at the time that having one obvious way to access the items would be preferred.

For example, `uname()[0]` doesn't mean anything to me without a comment or referencing the documetation, whereas `uname().system` does.

Access by numerical index hearkens back to C-style arrays and in my mind is an anti-pattern.
History
Date User Action Args
2022-04-11 14:59:30adminsetgithub: 84758
2021-03-05 01:10:03jaracosetmessages: + msg388140
2020-05-13 08:03:33lemburgsetstatus: open -> closed
resolution: rejected
messages: + msg368766

stage: resolved
2020-05-09 22:27:11steven.dapranosetnosy: + steven.daprano
messages: + msg368551
2020-05-09 19:23:30jaracosetmessages: + msg368537
2020-05-09 14:33:07jaracosetmessages: + msg368524
2020-05-09 14:06:56jaracocreate