Marc-Andre Lemburg <[email protected]> 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.
>
> I don't think these options are possible in the general case. It was what I
> attempted to do in the first place, but could not. Consider the situation
> where a namespace package is present or where a script uses pkg_resources to
> bootstrap itself (a very common case), or any other case where
> `platform.(anything)` is invoked before the "bypass" or "monkey-patch" has a
> chance to run. This happens when running the test suite for `cmdix` because
> pytest invokes pkg_resources to search for entry points and that code invokes
> `platform.system` (or similar) to evaluate environment markers long before
> the cmdix code has been imported.
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, e.g.
"""
#!/usr/bin/env python3
import platform
# Seed uname cache to avoid calling uname
platform._uname_cache = platform.uname_result(
system='Linux',
node='moon',
release='5.99.99',
version='#1 SMP 2020',
machine='x86_64',
processor='x86_64')
print ('Hello from uname.py')
print ('platform.uname() = %r' % (platform.uname(),))
"""
> Here's what happens:
>
> `platform.(anything)` runs `platform.uname` and `platform.uname` invokes
> `uname -p` in a subprocess _unconditionally_. Python doesn't provide hooks to
> monkey-patch that out before it gets invoked.
This is only true for the platform APIs which need information from
uname. Not in general.
>> Or you could call your utility something else.
>
> The point of this utility is to supply "coreutils" using Python. It's derived
> from an abandoned project called "pycoreutils", one purpose of which is to
> provide the core utilities on a minimal Linux distribution that doesn't have
> uname. Another is to supply coreutils on Windows. Having an alternate name
> isn't really viable when the purpose is to supply that interface.
>
>
> I do think your considerations are reasonable, and I'm close to giving up. I
> look forward to your feedback on the 'resolved-late' branch.
I don't have anything against making calling of uname lazy.
I also don't have anything against return useful information
rather than "unknown".
Your PR is missing tests, though, to support that it actually
returns the same values are before for a set of common platforms.
----------
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue35967>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
