Isn't it more Pythonic to simply call the function and an alternative path to handle the exception, anyway? Half of os needs to be tested for NotImplementedError or OSError if it's going to run anywhere outside the development environment anyway, otherwise you're stuck with only the most basic functions. What _would_ be handy is a list of what each function throws.
As for the original question, since it's duplicating or wrapping a module level functionality, it should be module level, rather than function level, and if there's a better design then it would need to be ported back to os as well. Although I could also see good reasoning behind os being implicitly or having to be explicitly imported to test for the less-compatible extensions. On Sun, Jun 14, 2020 at 11:14 PM Ivan Pozdeev via Python-Dev < python-dev@python.org> wrote: > > On 15.06.2020 8:45, Serhiy Storchaka wrote: > > 14.06.20 23:45, Ivan Pozdeev via Python-Dev пише: > >> 1. The documentation clearly says that it's supported depending on OS > flavor -- so if I want to know if I can supply it, I need to rather > >> check `os.name`. Those members are thus redundant. > >> > >> If the distinction is finer than os.name then I'd need some > other, case-specific check depending on what the distinction is; > >> alternatively, I could check the function's signature in its metadata > if the support is reflected in it. > > > > Yes, it is finer than os.name. It can depend on the kernel or libc > version (and we do not know which versions are required on every > > platform), and there are a lot of platforms besides the main three. The > user should not be expert in all platforms on which his program > > potentially can be ran. > > > > The function's signature is the same on all platforms. Just on some > platforms only default value can be passed (None for dir_fd) or only > > specific types of argument is accepted (path-like, but not int). > > Then a single boolean flag is clearly not enough. Compare: in > https://docs.python.org/3/library/resource.html , the set of present > RLIMIT_* > members shows which rlimits are available in the specific OS. > > So I guess you want some similar pointers that would show which relevant > #define constants (or other C-level entities that govern the > availability) were present at the time of compilation. > If availability is rather governed by a runtime than compile-time check, > then something to perform the same check should be introduced; the > distinction from .supports_stuff is it would be named after the check and > completely decoupled from any functions that might be affected by > the check. > > > > _______________________________________________ > > Python-Dev mailing list -- python-dev@python.org > > To unsubscribe send an email to python-dev-le...@python.org > > https://mail.python.org/mailman3/lists/python-dev.python.org/ > > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/YWYTZRLQK4ZHRFX3G3MJDGN6H4BJQCKN/ > > Code of Conduct: http://python.org/psf/codeofconduct/ > > -- > > Regards, > > Ivan > _______________________________________________ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/BJ7HFKNQAO3C44XQ75AEYCRTG5GMYTU5/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/UOTPZGFJ4IGPWDD2G5V5GDDP3G4NDY2H/ Code of Conduct: http://python.org/psf/codeofconduct/
