[issue40578] Deprecate numeric item access for platform.uname()

[Jason R. Coombs]

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 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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40578] Deprecate numeric item access for platform.uname()

[Marc-Andre Lemburg]

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 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.

--
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40578] Deprecate numeric item access for platform.uname()

[Steven D'Aprano]

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 breaking change. Why is it a problem that people 
are using something which is documented as a tuple as a tuple?

--
nosy: +steven.daprano

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40578] Deprecate numeric item access for platform.uname()

[Jason R. Coombs]

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 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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40578] Deprecate numeric item access for platform.uname()

[Jason R. Coombs]

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 warning... so deprecating it while supporting 
`tuple(result)` may not be possible.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40578] Deprecate numeric item access for platform.uname()

[Jason R. Coombs]

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 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.

--
messages: 368517
nosy: jaraco, lemburg
priority: normal
severity: normal
status: open
title: Deprecate numeric item access for platform.uname()
type: enhancement

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com