Repository navigation
len(platform.uname()) has changed in Python 3.9 #84750
Description
Activity
tucked commented
on May 8, 2020 tuckedmannequinMannequinAuthor518835f#diff-47c8e5750258a08a6dd9de3e9c3774acL741-R804
That diff changed len(platform.uname()) to 5 (from 6).
I noticed because we have some code that checks for 6 strs (arguably unnecessary),
but I can also think of contrived examples that would break (e.g. platform.uname()[-3]).
Interestingly, platform.uname()[5] still works.Was this effect intentional?
If it is important to retain the
len, it's probably also important to retain the[-N]accesses and possibly other behaviors of a length 6 tuple.Thanks David for the report and the draft PR (which helped me validate my thinking on the matter). In PR 20015, I've included additional tests. I've also re-written the compatibility functions to rely on the main
__iter__override.Another situation that's likely to be incompatible is pickleability. Is that important?
I'm tempted to make deprecated the use of
uname_resultfor anything other than attribute access (maybe with the ability to cast to a tuple, i.e.tuple(res)). The problem with namedtuples is that although they provide backward-compatibility for legacy behavior which returned tuples, they also bring that legacy as debt. By deprecating "access by index", that would constrain the interface to two basic usages: attribute access anditer()of all values.Hi Jason,
to achieve better backwards compatibility, it's probably better to use
the approach taken for CodeInfo in the codecs.py module:class CodecInfo(tuple): """Codec details when looking up the codec registry""" def __new__(cls, encode, decode, streamreader=None, streamwriter=None, incrementalencoder=None, incrementaldecoder=None, name=None, *, _is_text_encoding=None): self = tuple.__new__(cls, (encode, decode, streamreader, streamwriter)) self.name = name self.encode = encode self.decode = decode self.incrementalencoder = incrementalencoder self.incrementaldecoder = incrementaldecoder self.streamwriter = streamwriter self.streamreader = streamreader if _is_text_encoding is not None: self._is_text_encoding = _is_text_encoding return self def __repr__(self): return "<%s.%s object for encoding %s at %#x>" % \ (self.__class__.__module__, self.__class__.__qualname__, self.name, id(self))
This used to be a 4 entry tuple and was extended to hold additional
fields. To the outside, it still looks like a 4-tuple in all aspects,
but attribute access permits accessing the additional fields.--
Marc-Andre Lemburg
eGenix.comProfessional Python Services directly from the Experts (#1, May 09 2020) >>> Python Projects, Coaching and Support ... https://www.egenix.com/ >>> Python Product Development ... https://consulting.egenix.com/ ________________________________________________________________________
::: We implement business ideas - efficiently in both time and costs :::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
https://www.egenix.com/company/contact/
https://www.malemburg.com/Thanks Marc-Andre for the suggestion, but I don't think that approach is viable here. The whole point of bpo-35967 was to defer the execution of the
.processorbehavior until it was requested. The intention is not to extend the tuple, but to shorten it (at least not to require the last element to be provided at construction time). Perhaps I'm missing something here, so feel free to provide a more concrete example of what you have in mind. Just be cautious not to violate the intention ().Lines 784 to 787 in 77c6146
I created bpo-40578 to track deprecation of uname for positional access.
Ok, let me add some more context: When I wrote the uname interface
I was aware that calling the API will take some resources. That's
why I added the cache. IMO, that was enough as optimization.Now, you added a late binding optimization for the whole uname return
tuple to save the effort of going out to the system and figure our
the value using separate APIs or even shell access.I think this would have been better implemented in the various
uname() consumers
(Line 898 in 77c6146
and below), using a variant of the uname() API, say _uname(),
which leaves out the processor information for those APIs which don't
need it and only provide the late binding in processor() (which could
then also fill in the cache value for uname().The uname() API would then still do the full lookup, but applications
could then use the specialized API to query only the information
they need.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.--
Marc-Andre Lemburg
eGenix.comProfessional Python Services directly from the Experts (#1, May 09 2020) >>> Python Projects, Coaching and Support ... https://www.egenix.com/ >>> Python Product Development ... https://consulting.egenix.com/ ________________________________________________________________________
::: We implement business ideas - efficiently in both time and costs :::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
https://www.egenix.com/company/contact/
https://www.malemburg.com/you added a late binding optimization for the whole uname return
tuple to save the effort of ... shell access.It wasn't to save the effort and it wasn't an optimization. There was a fundamental race condition where it became impossible to implement a
unamecommand using Python becauseplatform.system()(or anything else that delegated toplatform.uname()) would unconditionally shell out touname, and this would happen early, before a library could intercept the behavior. See bpo-35967 for more details on the motivation and challenges.I think this would have been better implemented...
This idea is interesting, but I believe it also falls prey to the same race condition if any code calls
platform.uname()before a Python-based uname implementation has a chance to monkeypatch the behavior.May I suggest that you either revive the conversation in bpo-35967 or open a new ticket to discuss improving the implementation so that the details aren't lost in this ticket, which was specifically about compatibility issues?
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.I'll address this concern in the ticket I opened about the deprecation.
Hi Jason,
I think I have to review the whole set of changes again to understand what your motivation is/was.
For https://bugs.python.org/issue35967 I had already stated that your use case is not special enough to make the platform.py logic more complex.
BTW: Please don't open several different tickets for the same problem. It doesn't really help to see what is going on. I'll reopen the bpo-35967 to continue the discussion there.
Thanks.
@malemburg Not sure if this should be a new issue, but
platform.unamedocs for 3.12 still say:... Returns a namedtuple() containing six attributes: system, node, release, version, machine, and processor.
(my emphasis)
I've got python 3.10.6 installed, which returns 5 attributes, not including
processor, as expected from the discussion above:uname_result( system='Linux', node='MyName', release='5.15.0-48-generic', version='#54-Ubuntu SMP Fri Aug 26 13:26:29 UTC 2022', machine='x86_64' )Moved to a new issue.
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields: