[issue35967] Better platform.processor support

Change by Chih-Hsuan Yen : -- nosy: -yan12125 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35967] Better platform.processor support

Jason R. Coombs added the comment: I'm going to close this issue again, as the implementation is now present in at least a couple of releases. May I suggest that if there are ongoing concerns or issues to open up a new issue and reference this one and loop me into the conversation? I'm also

[issue35967] Better platform.processor support

Marc-Andre Lemburg added the comment: Thanks, Jason. I'll have a closer look at the issue and report back later this week. -- ___ Python tracker ___

[issue35967] Better platform.processor support

Jason R. Coombs added the comment: My bad. I probably could have been more proactive about providing a reproducer. The problem, as described above (msg335220) and in the associated cmdix ticket, is that invocation of `platform.(anything)` causes shelling out to execute "uname", so it's not

[issue35967] Better platform.processor support

Marc-Andre Lemburg added the comment: Reopening the ticket, since the implementation makes backwards incompatible changes to platform.uname(): see https://bugs.python.org/issue40570 for a discussion on a better approach to lazy evaluation of getting the processor information. Before we

[issue35967] Better platform.processor support

miss-islington added the comment: New changeset fb940408cea1fb34fed1418832f240f886dadf57 by Chih-Hsuan Yen in branch 'master': bpo-35967: Skip test with `uname -p` on Android (GH-19577) https://github.com/python/cpython/commit/fb940408cea1fb34fed1418832f240f886dadf57 -- nosy:

[issue35967] Better platform.processor support

Change by Chih-Hsuan Yen : -- nosy: +yan12125 nosy_count: 4.0 -> 5.0 pull_requests: +18917 pull_request: https://github.com/python/cpython/pull/19577 ___ Python tracker ___

[issue35967] Better platform.processor support

Change by Jason R. Coombs : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue35967] Better platform.processor support

Jason R. Coombs added the comment: New changeset 518835f3354d6672e61c9f52348c1e4a2533ea00 by Jason R. Coombs in branch 'master': bpo-35967 resolve platform.processor late (GH-12239) https://github.com/python/cpython/commit/518835f3354d6672e61c9f52348c1e4a2533ea00 --

[issue35967] Better platform.processor support

Jason R. Coombs added the comment: New changeset e72cbcb346cfcc1ed7741ed6baf1929764e1ee74 by Jason R. Coombs in branch 'master': bpo-35967: Make test_platform.test_uname_processor more lenient to satisfy build bots. (GH-19544)

[issue35967] Better platform.processor support

Jason R. Coombs added the comment: I'm hoping that PR 19544 fixes the issue. -- ___ Python tracker ___ ___ Python-bugs-list

[issue35967] Better platform.processor support

Gregory P. Smith added the comment: raspbian failure https://buildbot.python.org/all/#/builders/645/builds/31 -- nosy: +gregory.p.smith ___ Python tracker ___

[issue35967] Better platform.processor support

Change by Jason R. Coombs : -- pull_requests: +18891 pull_request: https://github.com/python/cpython/pull/19544 ___ Python tracker ___

[issue35967] Better platform.processor support

Jason R. Coombs added the comment: The aformentioned test broke tests in buildbots: https://buildbot.python.org/all/#builders/105/builds/779 -- ___ Python tracker ___

[issue35967] Better platform.processor support

Change by Jason R. Coombs : -- versions: +Python 3.9 -Python 3.8 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue35967] Better platform.processor support

Jason R. Coombs added the comment: New changeset 4b4e90a51848578dc06341777a929a0be4f4757f by Jason R. Coombs in branch 'master': bpo-35967: Baseline values for uname -p (GH-12824) https://github.com/python/cpython/commit/4b4e90a51848578dc06341777a929a0be4f4757f --

[issue35967] Better platform.processor support

Jason R. Coombs added the comment: In PR 12824 (https://github.com/python/cpython/pull/12824), I've developed a test that should assure the current output from uname().processor. I've merged those changes with PR 12239, which if the tests pass, should illustrate the values returned are

[issue35967] Better platform.processor support

Change by Jason R. Coombs : -- pull_requests: +12749 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35967] Better platform.processor support

Jason R. Coombs added the comment: > I don't quite follow: since you are the author of the tool, you can of course have your uname.py import platform and then apply one of the above tricks. I thought I'd tried that, but failed

[issue35967] Better platform.processor support

Marc-Andre Lemburg added the comment: On 08.03.2019 18:50, Jason R. Coombs wrote: > >> It's also easy to bypass that by simply seeding the global cache >> for uname(): _uname_cache. >> Or you could monkey-patch the platform module >> in your utility to work around the circular reference. >

[issue35967] Better platform.processor support

Change by Jason R. Coombs : -- pull_requests: +12227 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35967] Better platform.processor support

Jason R. Coombs added the comment: > It's also easy to bypass that by simply seeding the global cache > for uname(): _uname_cache. > Or you could monkey-patch the platform module > in your utility to work around the circular reference. I don't think these options are possible in the general

[issue35967] Better platform.processor support

Jason R. Coombs added the comment: In [this commit](https://github.com/jaraco/cpython/commit/acd024e2d4aa56f13d7bc165d10a35510e83a12b), I demonstrate the alternative approach I was considering that avoids calling "uname -p" until it's required, but otherwise retains compatibility by using

[issue35967] Better platform.processor support

Marc-Andre Lemburg added the comment: On 08.03.2019 18:00, Jason R. Coombs wrote: > >> Perhaps adding a more capable API to interface to /proc/cpuinfo > would be a good idea. > > The core concern I want to address is that it's not possible to use any > function in the platform module

[issue35967] Better platform.processor support

Jason R. Coombs added the comment: > Perhaps adding a more capable API to interface to /proc/cpuinfo would be a good idea. The core concern I want to address is that it's not possible to use any function in the platform module without invoking "uname -p", and thus it's not possible to

[issue35967] Better platform.processor support

Jason R. Coombs added the comment: > the output of platform.uname() needs to stay compatible to what the function > returned prior Do we really wish to retain the output for this unreliable interface, especially when it is not standardized and is returning improper information? Is it

[issue35967] Better platform.processor support

Marc-Andre Lemburg added the comment: Jason: StackExchange does have lots of good hints, but it's not always the correct. In this case, it's clearly wrong. uname -p has been available on many Unix installations for decades. I started writing the module back in 1999 and even then, the support

[issue35967] Better platform.processor support

Jason R. Coombs added the comment: Correction on last comment: s/Debian/Ubuntu/ -- ___ Python tracker ___ ___ Python-bugs-list

[issue35967] Better platform.processor support

Jason R. Coombs added the comment: [This answer](https://unix.stackexchange.com/a/307960/275034) is extremely helpful. `uname -p` isn't available on Linux except Fedora and late versions of Debian that apply the patch. This lack of consistency means that `platform.uname().processor` and

[issue35967] Better platform.processor support

Jason R. Coombs added the comment: After fussing with sysctl for a while, I'm fairly confident that one can't use sysctl on Linux reliably (https://stackoverflow.com/a/55066774/70170). I'll keep digging to see if I can find another implementation of `uname` that's used on Linux. --

[issue35967] Better platform.processor support

Jason R. Coombs added the comment: Hmm. But if I go to the Linux man page for uname (https://linux.die.net/man/1/uname) and follow the links to the source code, I end up at the same repository. So maybe the BSD man page is suitable for Linux. I'll work from that assumption for now.

[issue35967] Better platform.processor support

Jason R. Coombs added the comment: Reading further, the 'sysctl' call seems to only be for BSD (https://www.freebsd.org/cgi/man.cgi?sysctl(3)). I could find the man page for sysctl for BSD but not Linux. There is a _sysctl in Linux (http://man7.org/linux/man-pages/man2/sysctl.2.html), but

[issue35967] Better platform.processor support

Jason R. Coombs added the comment: Best I can tell, neither sysinfo nor sysctl are exposed in any way to Python, so it may not be possible to accurately load the processor information from those system calls without writing a wrapper in C. What I might try is to experiment with ctypes to

[issue35967] Better platform.processor support

Jason R. Coombs added the comment: Aha! It seems the 'sysinfo' call is for Solaris: https://docs.oracle.com/cd/E23823_01/html/816-5167/sysinfo-2.html -- ___ Python tracker

[issue35967] Better platform.processor support

Jason R. Coombs added the comment: The first call I see in that routine is to "sysinfo", but the signature of that function doesn't match what I find in the [man pages for that function](http://man7.org/linux/man-pages/man2/sysinfo.2.html). So that function must be coming from elsewhere.

[issue35967] Better platform.processor support

Marc-Andre Lemburg added the comment: Thanks. It would be good to do some before/after tests on popular platforms, e.g. a few Linuxes, MacOS, Windows. -- ___ Python tracker

[issue35967] Better platform.processor support

Jason R. Coombs added the comment: It won't be possible in general to emit what the function returned before, as `uname` is a symbolic reference to an arbitrary executable, which can vary by platform and release and local environment. What I might be able to do is find the implementation of

[issue35967] Better platform.processor support

Marc-Andre Lemburg added the comment: As the documentation says, the API is intended as fairly portable implementation of the Unix uname helper across platforms. It's fine to redirect this directly to e.g. /proc output instead of using the executable, but in whatever you do here, the output

[issue35967] Better platform.processor support

Change by Jason R. Coombs : -- keywords: +patch pull_requests: +12217 stage: -> patch review ___ Python tracker ___ ___

[issue35967] Better platform.processor support

Change by Jason R. Coombs : -- assignee: -> jaraco versions: +Python 3.8 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue35967] Better platform.processor support

Antoine Pitrou added the comment: Your proposal sounds fine to me. You could fall back on platform.machine() instead of calling `uname` explicitly. -- nosy: +pitrou ___ Python tracker

[issue35967] Better platform.processor support

Change by Ned Deily : -- nosy: +lemburg ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35967] Better platform.processor support

New submission from Jason R. Coombs : or: Unable to implement 'uname' on Python due to recursive call or: platform.uname() should avoid calling `uname` in a subprocess In [this issue](https://github.com/jaraco/cmdix/issues/1), I stumbled across a strange and somewhat unintuitive behavior.