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.

Author lemburg
Recipients jaraco, lemburg, pitrou
Date 2019-03-08.17:26:09
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <0728fd44-3b47-e0b3-22b6-78fbad1c3a70@egenix.com>
In-reply-to <1552064418.68.0.171775434915.issue35967@roundup.psfhosted.org>
Content
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 without invoking "uname -p", and thus it's not possible to implement "uname" in Python. No amount of supplementary interfaces will help with that.

I don't know where you get that idea from. The uname family of APIs
do use "uname -p" on platforms where this exists, but the other
ones don't.

It's also easy to bypass that by simply seeding the global cache
for uname(): _uname_cache. Or you could call your utility
something else. Or you could monkey-patch the platform module
in your utility to work around the circular reference.

To be clear: I do not consider your use case to be particularly common
enough to warrant changes to the module, but would welcome additions
which bring more or better functionality to the module, e.g. having
the processor variable return meaningful where it previously did
not (ie. uname() return '' for the processor entry), or adding
another API to provide more detailed information.
History
Date User Action Args
2019-03-08 17:26:09lemburgsetrecipients: + lemburg, jaraco, pitrou
2019-03-08 17:26:09lemburglinkissue35967 messages
2019-03-08 17:26:09lemburgcreate